Forem: Mauro de Carvalho

Componentes de um Navegador

Mauro de Carvalho — Sat, 02 Jul 2022 21:01:02 +0000

Um dos softwares mais utilizados em nosso dia-a-dia sem dúvidas é o nosso navegador (browser). Existem diversos no mercado, vai depender bastante do seu gosto na hora de escolher. Listando alguns, para fins de exemplos, temos o Firefox, Chrome, Brave, Safari e vários outros.

Mesmo com tantas opções, a essência de todos são bastante parecidas, não se tratando somente da finalidade, mas também em seus componentes internos. Esse texto busca explicar, em um nível mais superficial, os principais componentes que compõem um navegador.

Componentes de um navegador

Muitos navegadores possuem seu código aberto (Open Source), o que nos ajuda a compreender um pouco mais do funcionamento e decisões por trás do desenvolvimento dos mesmos. Alguns exemplos de navegadores de código aberto são: Firefox, Chromium, Brave, Basilisk, etc.

Olhando o código e a estrutura desses navegadores, começamos a reconhecer um certo padrão em seus componentes, são eles: User Interface, Browser Engine, Rendering Engine, Networking, UI Backend, JavaScript Interpreter e Data Storage.

A fim de entendermos melhor a responsabilidade de cada um deles, vamos abordá-los a seguir em pequenos tópicos. Novamente, não é intuito desta postagem nos aprofundarmos em cada um dos componentes, vamos tentar nos ater a pontuarmos suas principais características e responsabilidades.

User Interface

A User Interface está relacionado a todos aqueles "botões" da parte superior do navegador, como por exemplo, o de atualização de página, retorno (tanto para trás quanto para frente), salvar uma página como favorito, caixa de buscas, etc. Em resumo, é tudo aquilo que o usuário interage e que não esteja envolvido diretamente com a página do site que ele está acessando.

Browser Engine

O Browser Engine é o componente que funciona como um "intermediário", basicamente sendo uma ponte entre a User Interface e o Rendering Engine (vamos falar sobre ele a seguir). Ele consulta e atua juntamente com o Rendering Engine de acordo com as entradas recebidas através da User Interface.

Rendering Engine

O Rendering Engine é o componente responsável por exibir o conteúdo solicitado. Por exemplo, se o conteúdo solicitado for HTML, ele analisa HTML e CSS e exibe o conteúdo na tela. É interessante ressaltar que geralmente cada navegador possui seu próprio Rendering Engine. Por exemplo, o Firefox usa o Gecko, o Chromium usa o Blink, já o Basilisk utiliza a Goanna (que inclusive, é um fork do Gecko), etc.

Networking

O Networking é o componente responsável por gerenciar as chamadas de rede usando protocolos padrão, como por exemplo lidando diretamente com requisições HTTP, FTP, etc.

UI Backend

O UI Backend é o componente utilizado para desenhar widgets básicos como combo boxes e janelas. Por baixo, ele usa métodos de UI do próprio sistema operacional.

JavaScript Interpreter

O JavaScript Interpreter é o componente, como o próprio nome já sugere, responsável por analisar e executar código JavaScript. Muitas vezes esse componente interage diretamente com o Rendering Engine, onde depois que alguns resultados do cõdigo são gerados, eles devem ser encaminhado para exibição na página em que o usuário está navegando.

Data Storage

O Data Storage é o componente onde está a "camada de persistência". O navegador pode precisar salvar todos os tipos de dados localmente, como por exemplo, os famosos "cookies". A maioria dos navegadores também suportam mecanismos de armazenamento como localStorage, IndexedDB, WebSQL e FileSystem.

Aprofundando no Rendering Engine...

Por mais que o intuito dessa postagem seja ser um tanto quanto superficial em relação aos componentes de um navegador, não podemos deixar de fora um dos pontos mais importantes para se ter noção que é de como o Rendering Engine funciona.

Basicamente, assim que um usuário solicita um documento específico, o Rendering Engine começa a buscar o conteúdo do documento solicitado através do componente*Networking*. Logo após, o Rendering Engine começa a receber o conteúdo desse documento específico em blocos (geralmete de 8kb) e realizar o seguinte processo:

Para melhorar o entendimento da imagem acima, vamos pontuar cada um dos pontos desse fluxo:

1 - A página HTML solicitada é analisada em partes (incluindo os arquivos CSS externos e outros elementos de estilo). Feito isso, os elementos HTML são então convertidos em "nós" para formar uma “content tree” ou “árvore DOM”.

2 - Simultaneamente, o navegador também cria uma "árvore de renderização" (render tree). Essa árvore inclui tanto as "informações de estilo" quanto as instruções que definem a ordem na qual os elementos deverão ser exibidos.

3 - Além disso, a render tree passa pelo "processo de layout". Quando uma render tree é criada, os valores de posição ou tamanho não são atribuídos. Por conta disso, todo o processo de cálculo de valores para que tudo seja atribuído na posição desejada é chamado neste processo. Nele, cada nó recebe as coordenadas exatas, garantindo que cada um deles apareça em uma posição precisa na tela.

4 - A etapa final é "pintar" a tela, na qual a render tree é percorrida e o método "paint()" do Rendering Engine é invocado, pintando cada nó na tela com o auxílio do componente UI Backend.

Considerações finais

Se você se interessou por esta temática e deseja se aprofundar mais nela, eu super indico a leitura das referências dessa postagem e também pesquisar os códigos dos navegadores que são open source. Eu aprendi bastante fazendo isso, acredito que você também irá.

Referências

Visão geral sobre o HTTP

Mauro de Carvalho — Tue, 21 Jun 2022 02:43:37 +0000

HTTP é uma sigla para Hypertext Transfer Protocol, que significa: Protocolo de Transferência de Hipertexto. Basicamente, HTTP é um protocolo que permite a obtenção de recursos, como por exemplo: documentos HTML, imagens, vídeos, etc.

Ele é considerado um protocolo “Cliente-Servidor”, ou seja, ele determina padrões e define as regras para a troca de informações entre clientes e servidores. O WWW (World Wide Web) é totalmente construído com base na comunicação de clientes e servidores web.

A comunicação entre clientes e servidores é feita através da troca de mensagens individuais que são divididas entre as solicitações (requests) e respostas (responses). As mensagens enviadas pelo cliente (geralmente um navegador) a fim de se obter algum recurso é tida como request. Já a mensagem de resposta da solicitação enviada pelo servidor é tida como response.

PS: É válido ressaltar que as requisições são sempre iniciadas pelo destinatário (cliente).

O HTTP é um “protocolo da camada de aplicação”, que é executado no topo da pilha do modelo TCP/IP. O HTTP é enviado sobre o protocolo TCP, onde basicamente será criada uma conexão entre o cliente e o servidor, que será iniciada no momento do envio da solicitação, e após a resposta, a conexão será finalizada. Devido a essa característica, é dito que o HTTP é sem estado (stateless), já que não existe uma relação entre duas requisições sendo feitas através da mesma conexão.

Características do HTTP

Simplicidade: O HTTP foi projetado para ser de fácil legibilidade aos seres humanos. As mensagens podem ser entendidas por qualquer pessoa, facilitando o desenvolvimento e testes;
Extensível: Os cabeçalhos HTTP fazem com que o protocolo seja fácil de “estender”. Novas funcionalidades podem ser introduzidas pelo simples acordo entre um cliente e um servidor utilizando a semântica de um cabeçalho;
Sem estado: O HTTP é “sem estado”, ou seja, não há relação entre duas requisições sendo feitas através da mesma conexão. Como o fundamento básico do HTTP é não manter estados, utilizamos os Cookies HTTP para que as sessões tenham estados. Dessa forma, podemos adicionar os cookies aos cabeçalhos para permitir que a criação de sessão em cada requisição possam compartilhar o mesmo contexto/estado.
Conexões: As conexões são controladas pela camada de transporte, e portanto, estão fora do controle do HTTP, contudo, para cada par de requisição/resposta, uma conexão TCP é aberta. De fato, talvez caso haja a necessidade de haver várias requisições sendo feitas simultaneamente, não seja uma das característica mais agradáveis, e para contornar isso, foram criadas duas funcionalidades, uma no HTTP/1.1 e outra no HTTP/2.0. No HTTP/1.1 foi introduzida o conceito de “pipelining”, que dá uma maior controle para as conexões TCP utilizando o cabeçalho “Connection”. Já no HTTP/2.0, há a "multiplexação" de várias mensagens através de uma única conexão, ajudando a manter a conexão “mais quente”.

Fluxo HTTP

Quando um cliente quer se comunicar com um servidor, ele realiza os seguintes passos:

Abre uma conexão TCP: Uma conexão TCP será utilizada para enviar uma requisição e receber a resposta. Você pode criar uma conexão nova, reusar uma existente ou abrir várias conexões.
Envia uma requisição HTTP: Essas mensagens são legíveis aos seres humanos (Vamos dar um exemplo melhor na sessão Requisição HTTP);
O servidor devolve uma Resposta HTTP (Também falaremos melhor na sessão Resposta HTTP);
A conexão é fechada.

Requisição HTTP

Exemplo de uma requisição HTTP:

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: en

Podemos dividir as requisições nos seguintes elementos:

Um método HTTP é um “verbo”, como por exemplo GET, POST, DELETE, PUT ou também um substantivo como OPTIONS ou HEAD que são utilizados para definir qual operação o cliente quer fazer. Cada método é utilizado para uma função diferente por convenção, por exemplo o método GET é utilizado para obtenção de recursos e o POST para publicação de dados.
O caminho do recurso a ser buscado (URL);
A versão do protocolo HTTP;
Cabeçalhos opcionais que possuem informações adicionais para os servidores;
E para alguns métodos como o POST, um corpo com os dados;

Resposta HTTP

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: “51142bc1-744-479b075b2891b”
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

As resposta consistem em:

A versão do protocolo HTTP;
Um código de status (valos falar mais abaixo);
Uma mensagem de status, que basicamente é uma descrição do código de status;
Cabeçalhos HTTP, similar aos da requisição;
Opcionalmente, um corpo com dados do recurso requisitado;

Código de Status HTTP

Os códigos de status HTTP indicam se uma requisição HTTP foi corretamente concluída. Ao todo, as respostas são agrupadas em cinco classes:

1XX - Respostas de informação;
2XX - Respostas de sucesso;
3XX - Redirecionamentos;
4XX - Erros do Cliente;
5XX - Erros do servidor.

Para cada grupo desses, existe um código específico para uma determinada situação. Você pode ter acesso a cada um deles clicando aqui.

Diferenças entre o HTTP e o HTTPS

Por se tratar de um protocolo na camada de aplicação, o HTTP não precisa necessariamente se preocupar em como a mensagem é transmitida. Essa responsabilidade é da camada de transporte (conexão criada utilizando o TCP). Como o HTTP é um protocolo baseado em texto, pessoas má intencionadas podem “sniffar” a conexão e acessar os dados que estão sendo transmitidos. Para tornar a conexão entre o Cliente e Servidor mais segura, utilizamos uma conexão TCP criptografada com TLS (Transport Layer Security), e é justamente por estar utilizando esse tipo de criptografia que temos o “S” de Secure no final do HTTPS. Essa funcionalidade é oferecida pelo Certificado SSL, que por sua vez é oferecido pela maioria dos servidores.

Sumarizando algumas diferenças:

HTTPS é uma extensão do HTTP. Para que ele possa transmitir os dados de maneira segura, ele utiliza um outro protocolo chamado TLS.
HTTP utiliza a porta TCP 80 por padrão, já o HTTP usa a porta TCP 443;
O HTTP funciona na camada de aplicação, o HTTPS funciona na camada de transporte (TCP + TLS);
Não há necessidade de um certificado SSL para o HTTP, mas para o HTTPS, precisamos de um certificado SSL assinado e implementado por um CA (Certification Authority);
No HTTP não há necessidade de validação de domínio, enquanto para o HTTPS é obrigatória a validação do domínio;

Referências

Uma breve história sobre a Internet...

Mauro de Carvalho — Sun, 19 Jun 2022 20:50:27 +0000

Em resumo, a Internet é uma rede de conexões globais totalmente descentralizada, que permite o compartilhamento instantâneo de dados entre dispositivos. Demandou bastante tempo e esforço colaborativo para a Internet chegar ao seu estado atual. Ninguém é "detentor" da Internet, muito pelo contrário, ela só funciona graças a acordos voluntários de interconexões e tráfegos de informações feitos entre milhares de companias, universidades, governos e outras entidades.

A origem da Internet até chegarmos ao nível que temos hoje é muito interessante, e em alguns aspectos, bastante tensa. Nos meados dos anos 60, o mundo vivia um momento bem conturbado chamado de "Guerra Fria". Naquela época, havia uma divisão entre dois blocos políticos e ideológicos, comandados de um lado pelos Estados Unidos e do outro pela União Soviética. Nesse contexto, afim de continuar sendo possível manter o contato em casos de ataques às estações de comunicações, foi iniciado pelo governo norte-americano um projeto para criar uma rede descentralizada e resiliente que pudesse resistir a um cenário como esse.

O projeto dessa rede foi originada pela Advanced Research Projects Agency (ARPA), que era um órgão ligado ao Departamento de Defesa dos Estados Unidos, e recebeu o nome de ARPANET (Sigla para Advanced Research Projects Agency Network). Em outubro de 1969, a ARPANET teve seu primeiro sucesso ao transmitir uma mensagem através de sua rede da Universidade de Los Angeles até o instituto em Stanford em uma distância de quase 650 quilômetros. Em 1970, a já ARPANET estava consolidada com centenas de computadores conectados.

Neste mesmo período, Steve Crocker e sua equipe do Network Working Group estabeleceram o protocolo de controle chamado Network Control Protocol (NCP), que permitia o desenvolvimento de aplicativos a partir dos computadores conectados à ARPANET. Foi assim que, em 1972, Ray Tomlinson criou o software básico de e-mail, que se tornou o aplicativo mais importante da década e mudou a natureza da comunicação e colaboração entre as pessoas. Seu impacto foi tão grande que a ARPANET se afastou gradativamente do uso militar, aproximando-se do uso científico na disseminação de informações. Por esse motivo, em 1974, mais de 50 universidades americanas já estavam conectadas à ARPANET.

Apesar de seu sucesso, o protocolo NCP não era suficiente para se comunicar com redes ou máquinas fora da ARPANET. Por isso, em 1974, Robert Kahn e Vinton Cerf desenvolveram uma nova versão do protocolo que respondia a um ambiente de rede de arquitetura aberta, chamado de Transmission Control Protocol / Internet Protocol (TCP/IP). Este basicamente estabelece os padrões de como os dados devem ser agrupados, transmitidos, roteados e recebidos (até hoje!).

O TCP/IP foi criado com o intuito de permitir a comunicação padronizada entre computadores diferentes e garantir que essa comunicação persistisse, certificando que nenhum pacote de informações fosse perdido. Para melhor compreensão: o IP é o responsável pelo endereçamento dos pacotes de dados para os demais protocolos (existem vários outros de uso mais interno), já o TCP garante a continuidade do fluxo de informação, cuidando para que o processo ocorra sem problemas.

Em 1983, a ARPANET mudou o protocolo NCP para o novo TCP/IP. Neste mesmo período, o número de computadores e usuários na ARPANET continuou crescendo e, com o enfraquecimento da tensão causada pela Guerra Fria, ela acabou perdendo parte do "caráter militar". Por conta disso, ela acabou sendo divida em duas partes: A MILNET, que cuidaria apenas da parte bélica, enquanto o que restou da ARPANET seria utilizado para fins científicos. O seguimento "mais popular", foi o que teve maior desenvolvimento, servindo de base para as inúmeras redes conectadas entre si que conhecemos hoje como "Internet".

Em 1989 (ano que também foi desativada a ARPANET), Tim Berners-Lee desenvolveu a World Wide Web (WWW) para facilitar o trabalho colaborativo no Conseil Européen pour la Recherche Nucléaire (CERN). A WWW funciona como um sistema de distribuição de documentos de hipertexto interconectados e acessíveis por meio de um navegador web conectado à Internet. A WWW é composta principalmente por três entidades: HTML, URL e HTTP.

HyperText Markup Language (HTML) é um método de codificar a informação da internet, para ser exibida da maneira desejada. É uma linguagem de marcação utilizada na construção de páginas na Internet.
Uniform Resource Locator (URL) é um endereço virtual com um caminho indicando o local do arquivo, site, documento, ou qualquer item que possua uma localização.
HyperText Transfer Protocol (HTTP) é o protocolo usado para existir comunicação entre um sistema e outro. Ele que permite a transferência de dados, principalmente na Internet.

A WWW se tornou tão popular no CERN que, em 1991, foi aberto ao público externo. Graças a isso e a criação do primeiro navegador chamado de "Mosaic" em 1993, a recepção da Internet foi tão rápida que em 1997 havia mais de 200 mil sites online.

Referências

Gerenciando processos no Linux

Mauro de Carvalho — Sun, 14 Nov 2021 22:01:57 +0000

Introdução

Provavelmente você já deve ter ouvido sobre "processos" enquanto estava mexendo em seu computador. A maioria de nós talvez só nos damos conta da existência deles em "momentos ruins", por exemplo, quando alguma aplicação está travada e temos que "finalizar o processo dela". Contudo, fora o conhecimento em saber como finalizar o "bendito" para você continuar exercendo suas atividades, algo importantíssimo também é entender qual é a real importância de um processo.

O básico sobre Processos

Quando estamos trabalhando em um ambiente multiprogramado/multitarefa, o Sistema Operacional (SO) é responsável por gerenciar diversos programas executados "concorrentemente", controlando o compartilhamento dos recursos para cada um deles. Para que isso seja possível, todo programa executado deve sempre estar associado a um processo. Processo por sua vez, pode ser entendido como um programa em execução. Um programa de computador é uma "coleção passiva de instruções", enquanto que um processo é a "execução real" dessas instruções.

Cada CPU (Central Processing Unit, ou Unidade Central de Processamento) executa uma única "tarefa" por vez. Contudo, quando estamos lidando com um ambiente multiprogramado/multitarefa, há mecanismos que permitem que vários processos possam compartilhar CPUs e outros recursos da máquina, "comutando" entre tarefas que estão sendo executadas, sem ter que esperar necessariamente que cada uma delas de fato finalize (Essa "comutação", na qual me referi, irá variar de SO para SO se você quiser saber mais sobre isso, comece pesquisando por "Troca de Contexto" e "Compartilhamento de Tempo").

Imagine uma situação que temos duas tarefas: Uma mais lenta e outra mais rápida. Em um sistema com multiprogramação, as duas tarefas serão executadas "simultaneamente". Logo, a que é mais rápida estará disponível antes. Em sistemas sem multiprogramação, pode acontecer que da tarefa mais rápida ter que esperar a mais lenta terminar (vai depender do momento em que ela for "iniciada").

É válido ressaltar, que em sistemas multiprogramados, um processo pode passar por vários estados, que vão desde a sua criação até o seu término. A princípio, pode-se dizer que existe a ideia de sete estados de processos, são eles (não definitivamente nessa ordem ou com essas terminologias): Não Submetido, Criando, Pronto, Executando, Aguardando Evento Externo, Esperando e Encerrando. O SO reúne essas e outras informações do processo em uma estrutura de dados chamada PCB (Process Control Blocks).

Basicamente, o PCB permite ao SO localizar toda a informação do processo. O conjunto de PCBs forma o que chamamos de "tabelas de processos". É interessante ressaltar também que cada processo possui seu próprio PCB. A seguir temos algumas informações que geralmente estão contidas em um PCB:

PID (Identificador do processo);
Registradores da CPU;
O espaço de endereçamento do processo;
A prioridade do processo;
O estado do processo;
Informações sobre o escalonamento de processo;
Informações de entrada/saída;
O ponteiro para o próximo PCB;

Pronto! Acho que agora nós já começamos a entender melhor o conceito de processo, alguns de seus mecanismos, e também, como ele é gerenciado pelo SO. Vamos colocar um pouquinho de "mão na massa" e aprender alguns comandos interessantes para estarmos trabalhando com processos no Linux.

Visualização/Gerenciamento de Processos - Linux

Para melhorar um pouco mais os nossos estudos, estarei separando uma série de comandos interessantes para serem utilizados em sistemas baseados no Linux no que diz respeito à visualização e gerenciamento de processos. Provavelmente eu não vou conseguir cobrir tudo que cada um desses comandos é capaz de fazer, desta maneira, sugiro que você reserve um tempinho posteriormente para ler mais sobre eles utilizando o comando man + <nome_do_comando>.

Comandos ps e pgrep

Provavelmente esses são os comandos mais simples que você pode encontrar, em sistemas baseados no Linux, no que diz respeito a visualização de processos. Mesmo simples, não os subestimem, pois são extremamente poderosos se usados da maneira correta. Vamos iniciar com o comando ps.

O comando ps exibe um relatório simples contendo informações dos processos que estão ativos. É válido ressaltar, que ele funciona como uma espécie de "snapshot", ou seja, só exibe informações dos processos no momento exato em que o comando foi executado. Ele possui várias flags para melhorar sua visualização, abaixo estarei listando algumas para você testar em sua máquina:

ps (Comando em seu estado mais básico, exibe informações básicas sobre o seu shell atual e sobre o próprio comando ps);
ps -eF (Para listar todos os processos do sistema no formato padrão);
ps -eFH (Lista todos os processos do sistema no formato padrão, contudo, exibindo uma espécie de "árvore", associando o "processo filho" ao "processo pai");
ps -C chrome -o pid= (Exibe apenas os processos associados a um programa, nesse caso, exibe todos os processos associados ao "chrome");
ps -q 42 -o comm= (Exibe o nome do comando associado ao processo em questão, nesse caso, estamos querendo descobrir qual o comando relacionado ao processo "42");
ps -eo pid,ppid,stat,comm (Caso você queira especificar as colunas que serão exibidas, você pode usar a flag "-o" juntamente com os nomes das colunas desejados. Nesse exemplo, estamos solicitando uma lista contendo o PID, o PPID, o estado atual do processo e o comando que o originou - Para visualizar a lista completa de colunas disponível, utilize o comando man ps e vá até a sessão STANDARD FORMAT SPECIFIERS);

O comando prgrep, por sua vez, é um pouco mais simples. Ele basicamente irá listar os processos associados a um nome, e caso você desejar, com base em alguns filtros específicos. Abaixo, temos alguns exemplos de como utilizar o pgreg:

pgrep chrome (Lista os processos associados a um nome, nesse caso, estamos fazendo a listagem dos processos associados ao nome "chrome")
pgrep -u root,mdcg (Lista os processos pertencentes a um determinado usuário, no exemplo em questão, estamos fazendo a busca para os usuários "root" e "mdcg")
pgrep -o chrome (Exibe apenas o processo mais antigo associado a um nome, nesse caso, estamos verificando o do chrome)
pgrep -d, chrome (Por padrão, o comando pgrep irá exibir cada processo encontrado em uma nova linha. Utilizando a flag "-d", nós podemos especificar um novo delimitador. No exemplo em questão, estamos listando os processos associados ao chrome separados por vírgula)
pgrep -x chrome (O pgrep funciona fazendo uma busca com base no nome especificado, porém, talvez nós gostaríamos de fazer uma busca exata com base no nome informado. Para isso, nós podemos utilizar a flag "-x". No exemplo em questão, estamos fazendo uma busca dos processos que estejam associados exatamente ao nome/processo "chrome")
ps -fp $(pgrep -d, -x chrome) (Aqui estamos fazendo um uso do ps associado ao pgrep. Basicamente, estamos pegando o stdout do comando pgrep -d, -x chrome, e enviando para o stdin do comando ps -fp. Desta maneira, nós teremos um relatório mais detalhado dos processos relacionados ao "chrome")

Novamente, não deixe de utilizar o comando man para aprender ainda mais em como utilizar os comandos ps e pgrep.

Comando top

Um comando muito interessante para você estar acompanhando os processos no Linux em tempo real é o comando top. Ele possui diversas informações extremamente pertinentes para que você possa ter um maior controle do que está acontecendo em seu SO. Você pode acompanhar o consumo de CPU e memória, ter relatórios com o número tasks que estão ativas, além das informações que já tínhamos utilizando o comando ps, contudo, num formato muito mais "amigável".

É interessante falar também que o top permite diversas personalizações. Ao todo, a partir de um processo, você pode gerar até 58 colunas de informações (Utilizando o comando man, vá para a sessão 3 - FIELDS / Columns).

O top também é interativo, ou seja, durante a sua execução, você pode a todo momento estar modificando a forma em que os dados estão dispostos, a fim de ter uma visibilidade e um controle maior (Para ter acesso a lista de todas as interações permitidas pelo top, utilize o comando man e vá para a sessão 4 - INTERACTIVE Commands).

Abaixo estarei listando alguns comandos que eu geralmente uso quando estou trabalhando com o top, contudo, a minha lista não chega nem na metade de todas as opções que a ferramenta dispõe:

Setas direcionais (Mover a tela para visualizar melhor a informação);
Enter/Espaço (Atualização rápida (Refresh) - Você também pode utilizar a opção d / s para definir o intervalo de atualização automático, mas não é muito recomendado);
m (Melhora a visualização do uso de memória);
t (Melhora a visualização do uso de CPU, caso você queira visualizar o uso em cada um dos núcleos separadamente, basta digitar 1);
k (Finalizar um processo);
Z (Opção para mudar de cor. Você pode estar utilizando a tecla "a" para estar escolhendo também qual elemento da tabela que você deseja modificar a cor);
J (Altera entre o alinhamento à direita/esquerda para colunas numéricas);
j (Altera entre o alinhamento à direita/esquerda para colunas de caracteres);
u (Visualizar processos relacionados a um determinado usuário (blank para visualizar todos);
c (Exibe/Omite o "comando" originador do processo);
n (Quantidade de processos a serem exibidos na tabela);
x (Destaca a coluna que está selecionada. Esse comando será bastante útil quando estivermos trabalhando com a critérios de ordenação do top);
< ou > (Move entre as colunas que você deseja ordenar);
R (Ordem reversa da coluna selecionada);
M (Atalho para selecionar a coluna %MEM);
N (Atalho para selecionar a coluna PID);
P (Atalho para selecionar a coluna %CPU);
T (Atalho para selecionar a coluna TIME+);
q (Sair do top)

Existem muitos outros comandos disponíveis além desses que eu citei, novamente, sugiro que para você ter um maior aprendizado, utilize o comando man.

Outros dois programas interessantes que você pode estar dando uma pesquisada são o htop e o atop. Eles são bastante similares ao comando top, contudo, por não serem "nativos" não abordei aqui nessa postagem.

Comando kill e pkill

Uma vez que você agora consegue visualizar e identificar os processos, pode ser agora que você deseje "forçar a parada da execução de algum", seja porque ele está sendo problemático para o SO, ou apenas por pura vontade sua. Gostamos de nos referenciar a esse tipo de ação como "matar um processo" (por isso o nome dos comandos "kill"). Iniciaremos nossos exemplos com o comando kill.

Diferentemente do que se pensa, o comando kill não é feito diretamente para "matar" um processo. Ele na verdade é um comando para "enviar sinais" (signals) para um processo. Para ficar mais fácil o entendimento do que é um "signal", veja como uma forma de comunicação entre os processos. Existem vários signals disponíveis, mas ao meu ver, os mais conhecidos são o SIGINT (Interrupção, ctrl + c), SIGSTOP (Parada temporária, ctrl + z), SIGTERM (Término) e SIGKILL (Matar).

Por padrão, o comando kill irá enviar o signal SIGTERM para um processo, indicando que ele deve "terminar" sua execução. Porém, em alguns cenários, o SIGTERM não é o suficiente para fazer com que um processo "pare a sua execução", para que isso de fato aconteça, precisamos enviar um SIGKILL. Abaixo temos alguns exemplos de como executar o comando kill:

kill -l (Exibe todos os signals disponíveis. A partir dessa lista, você pode escolher entre três formas de enviar um signal: Pelo número; pelo nome completo do signal, nesse caso com o prefixo "SIG"; ou se desejar, você pode também omitir o "SIG").

Todos os comandos abaixo são equivalentes, basicamente eles estão enviando o signal SIGKILL para o processo associado ao PID 42:

kill -SIGKILL 42
kill -KILL 42
kill -s SIGKILL 42
kill -s KILL 42
kill -s 9 42

Lembra do comando pgrep? Temo uma versão muito parecida com ela (inclusive, de mesma autoria), chama pkill. Para utilizar o pkill, basta que você informe um nome, e caso sejam encontrados processos relacionados a ele, todos receberam um determinado signal. Por exemplo:

pkill chrome (Envia um signal SIGTERM para todos os processos associados ao "chrome");
pkill -KILL chrome (Envia um signal SIGKILL para todos os processos associados ao "chrome");

Fazendo uma menção honrosa rápida, posso indicar também o comando killall que funciona de maneira idêntica ao pkill.

Comando nice e renice

Como dito anteriormente, sistemas multiprogramados/multitarefas estão a todo o tempo gerenciando o tempo de CPU de cada processo, comutando entre tarefas que estão sendo executadas. Contudo, por trás dos algoritmos responsáveis por essas comutações, estão definidos também algumas "priorizações" para utilização de tempo de CPU. Caso você deseje especificar uma alta/baixa priorização para um determinado processo, você deve alterar seu Nice Value (niceness). Para isso, utilizamos os comandos nice e renice.

Um detalhe importante antes de iniciarmos de fato a explicação dos comandos nice e renice, é que o Linux trabalha com números de prioridade que vão de -20 a +20, porém, contraintuitivamente, a regra é inversamente proporcional: quanto menor o número especificado, maior sua prioridade. Em outras palavras, se você quiser que um processo tenha alta prioridade, coloque um valor baixo, como por exemplo -10.

A diferença primordial entre o nice e o renice, é a forma em que eles são "chamados". Se você precisa que um determinado processo inicialize já com uma prioridade alta/baixa, você deve utilizar o comando nice. Porém, se um processo já está em execução e você deseja alterar sua prioridade, utilizamos o comando renice. Simples assim. Abaixo temos alguns exemplos da utilização do nice e do renice:

nice -n 10 /opt/google/chrome/chrome (Atribui um certo valor de prioridade durante a inicialização de um determinado processo, no exemplo em questão, estamos inicializando o chrome com um valor "niceness" de 10);
renice -n 10 -p 42 (Atribui um certo valor de prioridade a um processo já em execução, nesse caso, estamos modificando o valor "niceness" do processo 42 para 10);
renice 10 42 (Comando idêntico ao anterior, contudo, suprimindo as flags "-n" e "-p", que são tidas como "padrão" durante a execução do comando);
renice 10 -u mdcg (Altera a prioridade de todos os processos associados ao usuário especificado, no exemplo em questão, estamos alterando o valor "niceness" de todos os processos associados ao usuário "mdcg" para 10);
renice 10 -p $(pgrep chrome) (Você pode utilizar também associações de comandos dessa forma, no exemplo em questão, capturando o stdout do comando pgrep chrome e inserindo como stdin no comando renice 10 -p, dessa forma, todos os comandos associados ao chrome terão seus respectivos valores "niceness" alterados para 10);

Conclusão

Enfim chegamos ao final de mais uma postagem. Eu sei, é muita informação, mas não se desespere! Alguns desses conceitos virão com a prática e com o passar do tempo e lembre-se que você pode sempre estar consultando a documentação de cada um desses comandos utilizando o comando man.

Muito obrigado pela leitura e até a próxima!

Bibliografia

Como a Internet funciona?

Mauro de Carvalho — Sun, 14 Nov 2021 21:34:14 +0000

Introdução

Você consegue imaginar como seria a sua vida, a partir de agora, sem a Internet? Tenho que admitir, para mim esse tipo de pensamento me causa bastante tristeza. Se em somente alguns momentos quando a "Internet cai" já deixa a gente com um misto de emoções que vão desde raiva, abstinência até a depressão (cruzes), imagina ficar pra SEMPRE sem Internet. Difícil, né? Hahaha, mas calma, o intuito dessa postagem não é te deixar triste e nem nada do tipo, mas sim, tentar explicar como essa tecnologia, que hoje é indispensável em nossas vidas, realmente funciona.

É válido ressaltar que as explicações aqui feitas serão um tanto quanto "superficiais". Não vou esmiuçar TOOODA a estrutura da Internet, dado que para alcançar tal feito, seria demandado muito tempo de estudo e diversos livros. Vou tentar explicar de forma resumida, a partir das minhas pesquisas e dos conhecimentos adquiridos, o que acontece desde o momento em que uma requisição é feita a um servidor qualquer, até a obtenção da resposta da mesma. Então sem mais delongas, vamos começar!

Cliente-Servidor

Um bom ponto de partida é iniciarmos explicando um dos modelos mais utilizados na comunicação distribuída, que é o "Cliente-Servidor". A julgar pelo nome do modelo, talvez o leitor já tenha percebido que há uma divisão entre duas entidades: O Cliente e o Servidor.

Vamos começar explicando o que seria o Servidor. Basicamente, este é um computador que estará executando um ou mais programas com o objetivo de prover recursos ou serviços dos mais variados tipos, que vão desde armazenamento de arquivos, serviços de e-mail, impressão, fax (alguém ainda usa isso?) entre muitos outros.

Já um Cliente tem um papel um pouco diferente nessa história. Basicamente, é ele que irá requisitar algum serviço ou recurso do Servidor. É interessante ressaltar que nesse modelo Cliente-Servidor, o pedido/requisição será sempre iniciado pelo Cliente.

Você deve estar se perguntando: "Tá.. entendi.. Mas como que a comunicação entre o Cliente e o Servidor ocorre nesse história toda?". Caaaalma, nós vamos falar disso em um capítulo mais abaixo chamado "A Rede" (spoiler). Esse parágrafo serviu apenas como uma "porta de entrada" para as próximas explicações, dito isso, vamos continuar!

Data Centers

Uma vez que você tenha entendido o "básico do básico" do modelo Cliente-Servidor, vamos falar um pouco sobre os famosos "Data Centers".

Lembra que no comecinho dessa postagem eu perguntei se você consegue imaginar como sua vida seria sem a Internet? Pois é, sem os Data Centers, hoje talvez boa parte dos serviços do mundo todo parariam por completo!

Um Data Center, a grosso modo, é como se fosse o "sistema nervoso" de algumas empresas de tecnologia. Basicamente, ele é uma infraestrutura totalmente projetada para concentrar servidores e diversos equipamentos de armazenamento, processamento e vários outros ativos computacionais, da forma mais segura possível, buscando sempre a preservação tanto física quanto lógica de tudo.

O objetivo principal de um Data Center é garantir a disponibilidade dos equipamentos que rodam sistemas fundamentais para o negócio de uma empresa. Basicamente, precisamos que todos os recursos cruciais para o bel funcionamento estejam disponíveis 24 horas, 7 dias por semana, 365 dias no ano.

Lembra que eu expliquei mais ou menos a função de um Servidor? Agora imagina só um monte deles juntos, servindo recursos dos mais diversos tipos, para milhares de Clientes mundo a fora, independente da hora do dia. Esse seria um "resumão" do que são os Data Centers.

A Rede

Agora nós aprendemos mais ou menos como funciona o modelo Cliente-Servidor, e também, sabemos de certa forma sobre o que é um Data Center e qual a importância dele.

Mas algumas coisas ainda não foram explicadas até aqui: Como que clientes e servidores se comunicam? Como é possível, dado a imensa quantidade de computadores pelo mundo, que uma requisição seja enviada para o servidor específico e a resposta volte sem se perder no meio do caminho? Vou tentar responder essas perguntas logo a seguir.

No momento em que eu estava escrevendo esse parágrafo, eu dei uma pausa para usar uma ferramenta para calcular a distância da minha casa até um dos Data Centers do Google que fica na cidade de Lenoir, na Carolina do Norte, EUA (eu tava meio entendiado, não me julgue). Talvez eu tenha uma certa vantagem em relação aos leitores de outras localidades aqui do Brasil, já que eu moro na região mais ao norte do país, mas mesmo assim, a distância ainda foi bem alta, aproximadamente uns 6.689,97 km. O tempo de voo médio que um avião levaria saindo aqui da minha casa (o quê!?) até o a esse Data Center, seria algo entorno de umas 8 horas e meia.

Engraçado, mesmo sabendo das distâncias físicas, como é possível que o tempo de resposta de uma requisição feita do meu computador até um dos servidores do Google, demore somente 53.4 milissegundos? Ora, essa pergunta é muito fácil de ser respondida: É graças aos aproximadamente 1.2 milhões de quilômetros de fibra óptica interligados em todos os países do mundo, que emitem sinais por meio de pulsos eletromagnéticos (luz, radiação infravermelha ou qualquer outra radiação eletromagnética). Ahhh, então é graças a isso, né.. PERA! 1.2 MILHÕES DE QUILÔMETROS?!

Só pra você ter uma noção, a circunferência da terra tem aproximadamente uns 40.075 km, isso quer dizer que com o comprimento de toda a fibra óptica usada para nos conectarmos, daria pra gente dar quase umas 30 voltas ao redor dela.

Não se precipite. Pode até parecer, mas a internet não é só um "cabão gigantesco de fibra óptica ligando todo mundo, que transmite dados de maneira super-rápida", afinal, hoje existem uma série de dispositivos que estão conectados a Internet e não precisam de cabo nenhum, não é mesmo? Mas então como que essa "mágica" acontece? Para respondermos melhor essa pergunta, precisamos entender mais alguns conceitos básicos que são os roteadores, modems, provedores, endereços IPs, protocolos e pacotes. Eu sei, eu sei.. É muita coisa, mas relaxa, eu vou tentar explicar de uma forma que você possa compreender a correlação entre cada um deles.

Roteadores

Vamos começar falando um pouco sobre os roteadores. Para iniciarmos nossa discussão, eu vou propor uma reflexão (de novo isso?).

Imagina só que para que dois computadores se comunicassem, precisássemos que existisse uma conexão entre eles, por exemplo, através de um cabo Ethernet. Beleza, para conectar dois computadores, precisaríamos de apenas um cabo, certo? Agora imagina que precisássemos conectar 10 computadores através de cabos Ethernet, você sabe quantos cabos iriamos precisar mais ou menos? Seriam necessários 45 cabos! Agora eu vou mais além, imagina se a gente fosse conectar todos os dispositivos do mundo usando cabos? A gente não ia conseguir nem sequer andar no meio de tanto fio, não é mesmo? Então como que a gente fez pra resolver esse problemão? Ora, através da utilização dos roteadores!

Um roteador nada mais é que uma espécie de "computador pequenininho", super simples, que possui apenas uma única tarefa: Ele precisa garantir que a mensagem enviada de um determinado computador, chegue ao computador de destino correto. Para melhorar a explicação, imagina que vamos enviar uma mensagem do computador A para o computador B, então basicamente o que ocorrerá é que o computador A envia a mensagem para o roteador, que por sua vez encaminha para o computador B, e garante que ela não seja entregue, por exemplo, para o computador C.

Dessa forma, voltando a considerar que tivéssemos 10 computadores na nossa rede, ao invés de 45 conexões entre todos os computadores, iriamos precisar apenas que cada um deles se conectasse ao roteador, dessa forma, teríamos apenas 10 conexões, ou melhor ainda, já que temos "Roteadores Wi-Fi", não precisamos de cabo nenhum, né?

Mas calma! Não existe apenas um roteador conectando todos os computadores do mundo todo! Lembra que eu falei que o roteador é um "computador pequenininho"? Por se tratar exatamente de um computador, ele pode se conectar a outro roteador, que por sua vez se conecta a outro, e a outro, e a outro… Mas isso só é possível se estivéssemos falando de uma rede local. Ainda com a solução do roteador, se quiséssemos nos conectar ao mundo todo, iriamos continuar precisando de muuuitas conexões de cabos de rede entre outros computadores e roteadores. E é a partir dessa problemática que vamos para o nosso próximo dispositivo que ajuda a resolver esse problema, que é o modem.

Modems

Há um certo tempo atrás, foi criada uma grande infraestrutura, extremamente complexa, que permitiu com que nos comunicássemos com qualquer pessoa no mundo através de uma ligação telefônica. O que poucas pessoas sabem no entanto, é que essa infraestrutura também pode ser utilizada para nos conectarmos hoje a Internet. Porém, como os tipos de dados que utilizamos na rede de computadores são diferentes dos dados que são utilizados em redes telefônicas, precisamos de uma forma de gerenciar isso tudo. É aí que o modem entra.

Basicamente, o modem serve para transformar informações da nossa rede em informações gerenciáveis pela infraestrutura telefônica e vice-versa. Ele modula um ou mais sinais de onda portadora para codificar informações digitais para transmissão, e desmodula sinais para decodificar as informações transmitidas (acho que peguei um pouco pesado nessa explicação, mas deu pra entender, né?).

Pronto, agora estamos conectados à estrutura telefônica e podemos reaproveitá-la para conectar nossos computadores a outros computadores por meio dela. Mas estamos esquecendo de um detalhe muito importante: Nós somos cobrados para que possamos nos conectar a essa infraestrutura. E quem faz essa cobrança, e de quebra facilita ainda mais com que possamos nos conectar a outros computadores no mundo, é justamente o nosso "Provedor" (Internet Service Provider ou ISP).

PS: Existem muitas outras formas de nos conectarmos a Internet além da utilização dedicada de linhas telefônicas, mas para fins didáticos e também para não nos alongarmos explicando cada uma delas, vamos nos focar nossa jornada utilizando a conexão via linha telefônica, tá bom?

Provedor

Vamos recapitular um pouco alguns elementos da rede que foram explicados até aqui:

Temos os nossos dispositivos (computadores, smartphones, etc);
eles podem estar conectados localmente através de um roteador;
o roteador por sua vez se conecta ao modem;
o modem transforma informações da nossa rede em informações gerenciáveis pela infraestrutura telefônica;
estamos agora conectados a estrutura telefônica.

O próximo passo agora é enviar as mensagens da nossa rede para a rede que queremos alcançar, por exemplo, acessar através do navegador do meu computador uma página do Google. Para facilitar esse envio de mensagem, contratamos um Provedor (Internet Service Provider ou ISP). Um Provedor é uma empresa que gerencia alguns "roteadores especiais" que são conectados entre si, e que também, podem acessar roteadores de outros Provedores que seguem a mesma lógica.

Deste modo, a mensagem parte da nossa rede local, e então é transportada para a "rede de redes" do Provedor, e assim, para a rede de destino na qual a mensagem deverá ser entregue. Basicamente, essa é a estrutura permite que os computadores do mundo todo, uma vez que fazem parte dessa graaande rede, possam se comunicar.

Certo, acho que nós conseguimos entender como os computadores na Internet estão conectados, mas se você é um cara curioso, deve estar se perguntando agora: No momento que eu envio uma mensagem de um computador, que está em uma rede específica, para outro, sei lá, há milhares de quilômetros de distância, em uma rede completamente diferente, como é possível que essa mensagem não se perca no caminho? Ou melhor, como é possível ainda que depois dela ter chegado no destino, ela possa voltar em formato de resposta para a origem? Mistério? Magia? Óbvio que não, né? E é aqui que teremos a nossa "deixa" para explicarmos sobre endereço IP, protocolos e pacotes.

Endereço IP

Todos os dispositivos que estejam conectados na Internet, desde computadores até smartphones, smart TVs, impressoras, câmeras de segurança, etc, recebem um endereço único de identificação chamado de "Endereço IP".

Atualmente, possuímos duas versões de para os endereços IPs. A primeira, que mais "comumente" utilizada, é o IPv4, que permite que tenhamos cerca de 4,294,967,296 de endereços únicos na Internet. Já a segunda versão, que é o IPv6, possui aproximadamente 79 octilhões de vezes mais endereços em relação ao IPv4. Não sei bem ao certo hoje, mas levando em consideração que o planeta terra tenha aproximadamente 6 bilhões de habitantes, isso daria um pouco mais de 56 octilhões de endereços para cada um deles. E ae, tu conseguiria gastar todos os endereços disponíveis pra você, hahaha?

Para fins didáticos, e também pra não confundir muito a sua cabeça, vamos nos ater ao IPv4, tá bom? Basicamente, os endereços IPs nessa versão possuem um formato nnn.nnn.nnn.nnn, onde cada conjunto de "nnn" é um número que vai de 0 até 255.

Mas agora imagine a dificuldade para nós, meros mortais, lembrarmos o endereço IP de um computador específico. Difícil, né? E a julgar pela forma com que você está familiarizado a utilizar a Internet, você não sai digitando nenhuma série de "nnn.nnn.nnn.nnn" para se conectar a um site, e sim, algo parecido com "www.algumacoisa.com". Basicamente esse "algumacoisa.com", é o que chamamos de nome de domínio, que nada mais é que um "apelido" para o seu real endereço IP do computador, que sei lá, talvez fosse 175.234.12.100 (Não, esse não é o meu IP). Para não nos alongarmos muito, vou deixar a explicação de como essa tradução é feita para outra postagem, mas se o leitor tiver interesse sobre o assunto, basta pesquisar sobre DNS (Domain Server Name).

Certo, agora nós entendemos que não há como uma determinada mensagem se perder no caminho de forma acidental, uma vez que tanto o computador origem, quanto o computador destino, possuem endereços únicos em toda a rede. E criando um gancho agora para o nosso próximo tópico, talvez o leitor notado, uma vez que tenha chegado até aqui, que eu utilizei várias vezes a palavra "mensagem" quando precisava dar exemplo de uma comunicação entre dois computadores (até deixei em negrito um exemplo aqui no começo desse parágrafo). Vamos agora tentar entender o que seriam algumas dessas "mensagens" compreendendo o conceito de protocolos e pacotes.

Protocolos

Imagina só se tivéssemos apenas uma única língua universal e que essa permitisse que todas as pessoas do planeta pudessem se comunicar sem nenhum problema. Seria maravilhoso, né? Só pra você ter noção, se alguém quisesse ser capaz de conversar com qualquer pessoa no mundo, precisaria aprender um pouco mais de 6 912 idiomas diferentes.

Um protocolo de rede funciona exatamente como um "língua universal" entre todos os computadores do mundo, independente do sistema operacional ou fabricante. Uma vez que os computadores estão conectados na Internet, eles vão se comunicar utilizando protocolos específicos.

Para cada tipo de serviço irá existir um protocolo de rede diferente. Se você deseja assistir um vídeo no seu navegador, enviar e receber mensagens no "zap", baixar e subir arquivos, acessar algum site específico, para cada uma dessas tarefas existe um protocolo a ser seguido entre todos os computadores.

Os dois protocolos mais importante para nós, nesse momento, são o TCP/IP e o HTTP/HTTPS. O protocolo TCP/IP, é responsável pelo envio e recebimento de dados, identificando as melhores rotas para a comunicação entre dois locais. Já o HTTP, é o protocolo utilizado para acessar páginas na internet, como por exemplo essa postagem que você está lendo agora. É válido falar também sobre o HTTPS que funciona da mesma forma que o HTTP, contudo, ele possui uma "camada de proteção extra de segurança" durante as trocas de mensagens entre os computadores.

Existem diversos outros protocolos que infelizmente não será contemplado aqui na nossa explicação, mas se o leitor sentir vontade de aprender mais, pode pesquisar por UDP, DHCP, FTP, SFTP, SSH, SMTP, IMAP (é quase uma sopa de letrinhas).

Ufa, estamos quase chegando ao fim, agora só precisamos saber um último conceito, intrinsecamente ligado aos protocolos, que são os pacotes.

Pacotes

A gente não se dá conta, mas tudo que você utiliza no seu computador, na parte de software é claro, é uma imensa coleção de 0's e 1's. Essa postagem que você está lendo agora por exemplo, chegou até você no formato de uma graaande coleção de 0's e 1's. Basicamente, o conteúdo que você está acessando agora, está armazenado em um servidor e precisou ser transportado, seguindo toooda a estrutura que explicamos até aqui, até chegar ao seu computador. Mas sabe o que realmente faz com que a transferência de dados aqui na Internet seja extremamente eficiente? É exatamente pela forma em que esses 0's e 1's são divididos e transmitidos em vários pequenos pedaços chamados de pacotes.

Cada pacote, além de uma pequena parte da informação, também irá possuir um "cabeçalho" no qual contém informações importantes para a transmissão, como o endereço do servidor/cliente, prioridades, etc.

Uma vez que esses pacotes são criados, eles começam a ser transferidos um a um pela Internet até que alcancem o computador de destino. A medida que os pacotes começam a chegar no computador de destino, inicia-se um processo para "juntá-los" novamente. Para que haja uma consistência na forma em que eles são transmitidos pela rede e também reconstruídos após chegarem ao seu desígnio, é que são utilizados os protocolos (que explicamos anteriormente). Para cada serviço (vídeo, chat, e-mail, armazenamento, etc), existirá um protocolo diferente para a manipulação dos pacotes.

Conclusão

Nem de perto eu cheguei a tratar de todos os assuntos por trás de como a Internet REALMENTE funciona. Como eu disse no começo dessa postagem, seriam necessários muito tempo de estudos e vários livros para englobar tudo que é imprescindível pra entender, com extrema maestria, o funcionamento por completo da Internet. Mas de qualquer forma, eu espero que com esse resumão você possa ter aprendido, "superficialmente", como essa tecnologia que hoje é indispensável em nossas vidas funciona.

Obrigado pela leitura e até a próxima! :-)

Bibliografia

Criando um pendrive bootável live com Kali Linux

Mauro de Carvalho — Sun, 14 Nov 2021 20:39:03 +0000

Introdução

Se você já faz parte ou tem interesse de entrar no mundo do hackvismo, provavelmente já deve ter ouvido falar do Kali Linux. Nessa postagem, eu pretendo falar um pouco sobre essa distribuição, e também, ensiná-lo como você pode estar criando um pendrive bootável no modo live com o mesmo, utilizando apenas a linha de comando do seu terminal. Sem mais delongas, vamos começar!

PS: Caso você não saiba o que é "bootável no modo live", significa que você poderá inicializar o sistema operacional direto do seu pendrive, com isso, você não precisará necessariamente fazer a instalação do Kali Linux em sua própria máquina.

Sobre o Kali Linux

O Kali Linux é uma distribuição GNU/Linux baseada no Debian, totalmente open source, que é mantido e financiado pela Offensive Security. Ele é usado para pentesting, avaliações de segurança de redes e até mesmo para forense computacional. O Kali Linux vem com mais de 300 ferramentas para executar testes de diversos tipos, que englobam desde a etapa de "information gathering" (coleta de informações) até a geração do relatório final. Com a distribuição, você vai ter um arsenal com uma infinidade exploits, sniffers, scanners, password crackers, wireless hacking tools e muito mais!

Caso você queira ler mais sobre o Kali Linux, eu sugiro que você comece pela documentação oficial que pode ser encontrada em https://www.kali.org/.

Instalando o Kali Linux no seu pendrive

Agora que já aprendemos um pouquinho sobre o Kali Linux, vamos ao tópico principal dessa postagem que é justamente criar um pendrive bootável no modo live com a distribuição. Como dito anteriormente, iremos fazer tudo utilizando apenas a linha de comando. Caso você não goste dessa abordagem (tsc tsc), no final eu irei postar algumas ferramentas que você poderá estar utilizando para a mesma finalidade.

Inicialmente, você precisará de um pendrive com no mínimo 4GB de capacidade. Com ele em mãos, vamos formatá-lo para que possamos deixar tudo nos trilhos para o momento em que iremos inserir o Kali Linux e torná-lo bootável. Desta maneira, conecte o dispositivo ao seu computador e vamos em frente!

Formatando o pendrive

O primeiro comando que iremos utilizar é o lsblk, que basicamente irá listar todos os dispositivos de armazenamento em bloco que estão conectados ao nosso computador. Geralmente nós identificamos o "nome" do pendrive pelo seu tamanho de armazenamento, mas se você estiver com dúvidas, sugiro que você utilize o comando duas vezes, uma sem o pendrive conectado e outra com ele. No meu caso, após utilizar o comando, identifiquei que o "nome" do bloco relacionado ao pendrive é sdb:

Agora que identificamos o nosso dispositivo, iremos utilizar o comando para formatá-lo, desta forma, certifique-se de não ter nada de valioso armazenado nele, pois após a execução do comando, o pendrive será completamente limpo!

Uma vez que o aviso foi dado, para formatar o pendrive iremos utilizar o seguinte comando juntamente com o "nome" que identificamos anteriormente (no meu caso, será /dev/sdb):

sudo dd if=/dev/zero of=/dev/sdb bs=4k status=progress && sync

O comando acima é bloqueante e pode levar vários minutos para ser concluído, por isso, seja paciente. Durante a execução do comando veremos algumas saídas desse tipo:

Após o término eis o que veremos:

Pronto, nosso pendrive está completamente limpo, mas ainda não acabamos. Precisamos criar uma nova tabela de partição para o dispositivo. Para isso, iremos utilizar o seguinte comando juntamente com o "nome" do bloco do pendrive que identificamos anteriormente (no meu caso, /dev/sdb):

sudo fdisk /dev/sdb

Após a execução desse comando, ele irá lhe pedir algumas instruções para a criação da tabela de partição. Abaixo, segue o fluxo que iremos digitar, bem como suas respectivas saídas:

Pressione "o" para criar uma nova Tabela de Partição DOS vazia.
Pressione "n" para adicionar uma Nova Partição.
Ele irá pedir para você informar o Tipo da Partição, caso você não tenha preferência, pressione "p".
Agora será requerido que seja informado o Número da Partição, apenas pressione "enter".
Pressione "enter" novamente para a opção do Primeiro Setor.
Novamente pressione "enter" para a opção do Último Setor.
Por fim, pressione "w" para escrever a nova Tabela de Partição DOS no dispositivo e sair.

Vamos utilizar o comando lsblk novamente para assegurarmos que de fato a nova partição foi criada. No meu caso ela foi, observe que tenho um "sub-bloco" de sdb chamado sdb1:

Estamos quase acabando! Precisamos agora criar um sistema de arquivos MS-DOS na nossa nova partição. Para isso, iremos executar o seguinte comando informando o "nome" identificado do "sub-bloco" após a execução do lsblk (no meu caso, /dev/sdb1):

sudo mkfs.vfat /dev/sdb1

Após a execução do comando, teremos uma saída desse tipo:

Pronto, agora basta desconectarmos o pendrive e conectarmos ele novamente para ver se o nosso computador está reconhecendo-o. Você pode utilizar o comando eject para desconectar o dispositivo (substitua /dev/sdb pelo nome do seu bloco):

sudo eject /dev/sdb

Ufa, formatamos o nosso pendrive utilizando a linha de comando! De fato, existem maneiras mais "simples" para desempenharmos essa função, mas durante a escrita dessa postagem, eu achei essa a mais "hacktificante" (risos).

Baixando e instalando o Kali Linux no seu pendrive

Uma vez que concluímos a etapa de formatação do pendrive, agora iremos nos ater a como deixá-lo "bootável".

Antes de mais nada, você irá precisar baixar a imagem ISO do Kali Linux. Para isso, basta acessar a seguinte URL: https://www.kali.org/downloads/. Nela você irá encontrar uma lista contendo várias versões do Kali Linux, contudo, para que tenhamos um maior êxito na nossa operação, eu sugiro que você baixe as versões que tenham "(live)" no final, como essa:

Fique a vontade para escolher entre 64-bit ou 32-bit, essa escolha vai depender do desempenho da sua máquina e/ou pendrive. Se for uma máquina/pendrive mais "humilde", opte por 32-bit, do contrário, 64-bit é uma excelente escolha. A única coisa que irá fazer realmente diferença na escolha de imagem ISO, como dito anteriormente, vai ser o fato dela ter ou não "(live)" no final. Dessa forma, baixe a que tenha esse sufixo, por favor.

Agora que baixamos o Kali Linux, vamos executar os seguintes passos para deixar o nosso pendrive bootável:

Abra novamente o terminal
Utilize o comando cd para ir até o diretório onde a imagem ISO do Kali Linux se encontra
Conecte o pendrive ao seu computador
Descubra o "nome" do bloco relacionado ao pendrive, no caso, o do meu é sdb (Utilize o comando lsblk para descobrir)
Execute o seguinte comando no diretório em que a imagem ISO do Kali Linux está (no meu caso o nome da imagem é "kali-linux-2020.2-live-amd64.iso", se for diferente do seu, lembre-se de substituir pela que você baixou):

sudo dd if=kali-linux-2020.2-live-amd64.iso of=/dev/sdb bs=4M status=progress

Aguarde alguns instantes. Como dito anteriormente, o comando dd é bloqueante, então pode demorar um tempinho até que a cópia seja concluída.
Quando o processo estiver terminado, você verá uma saída muito parecida com essa:

Pronto! Agora basta só ejetar o pendrive e conectá-lo novamente para ver se tudo deu certo. Quando você acessar o conteúdo do pendrive, provavelmente vai se deparar com uma estrutura muito parecida (para não dizer igual) com essa:

Agora basta você reiniciar o seu computador, acessar a BIOS ou qualquer outra função durante o boot para determinar qual será o tipo de inicialização do computador, e alterá-lo para que isso seja feito pelo seu pendrive. Voilà, agora você poderá utilizar o Kali Linux direto do seu pendrive, em qualquer computador!

Menção honrosa

Como foi dito logo no começo, caso essa abordagem não seja interessante para você, estarei listando aqui algumas ferramentas que você poderá estar utilizando para alcançarmos o mesmo objetivo. Lembrando novamente que caso o seu intuito seja criar um bootável no modo live, é interessante que você baixe a imagem que contenha o sufixo "(live)", do contrário, será apenas um instalador normal. Eis algumas ferramentas que você poderá estar utilizando:

Dessa lista, eu particularmente recomendo fortemente a utilização do "Etcher", ele é bastante simples e fácil de usar.

Considerações Finais

Caso você tenha seguido todos os passos aqui descritos utilizando a linha de comando, sugiro que você se aprofunde um pouco sobre as instruções que utilizamos que foram: lsblk, dd, mkfs.vfat. Para isso utilize o comando man + {nome-da-instrução}. Abaixo eis um print da utilização do comando man lsblk:

Ser curioso é um passo muito importante no caminho para se tornar um hacker, desta maneira, ao invés de simplesmente copiar os comandos, eu sugiro que você entenda como eles funcionam, para que assim você possa estar fazendo alguns acréscimos, deixando-os mais otimizados e também para que possa estar aplicando-os em outras situações.

Agradeço a sua leitura e espero ter contribuído um pouco para o seu aprendizado. Até a próxima!

Semantic Versioning

Mauro de Carvalho — Sat, 13 Nov 2021 02:29:18 +0000

Essa é a terceira postagem correspondente à minha jornada para ser um desenvolvedor melhor. Novamente, gostaria de deixar claro que estou seguindo o excelentíssimo Web Developer Roadmap 2021, criado por Kamran Ahmed, como base para os meus estudos. Caso você queira ler a a minha postagem anterior, na qual eu resumi um pouco sobre o DRY, YAGNI e KISS, clique aqui.

Introdução

Quando entramos no mundo do gerenciamento de software, existe algo extremamente enfadonho e que assombra qualquer equipe de desenvolvimento conhecido como Inferno das dependências (“dependency hell”). Quanto mais o sistema cresce, e consequentemente quanto mais pacotes são adicionados a ele, maior é a probabilidade de quiçá, um dia, você encarar o abismo. E meu amigo, citando Friedrich Nietzsche, quando se olha muito tempo para um abismo, o abismo olha para você.

Certo, eu concordo. Talvez eu realmente tenha pegado um pouco pesado invocando Nietzsche (risos), mas vamos continuar falando um pouco sobre esse bendito Inferno das dependências, e para isso, devemos entender dois conceitos e como eles ocorrem. São eles:

Bloqueio de versão: Ocorre quando as especificações das dependências são muito ‘amarradas’, ou seja, quando há uma incapacidade de atualizar um pacote sem ter de liberar novas versões de cada pacote dependente.
Promiscuidade da versão: Ocorre quando as dependências são vagamente especificadas, ou seja, assumindo compatibilidade com futuras versões mais do que é razoável.

O Inferno das dependências é exatamente onde você está quando o Bloqueio de versão e/ou a Promiscuidade da versão impedem que você siga em frente de maneira fácil e segura.

Contudo, existem meios de evitar que problemas como esse aconteçam, e é aí que entramos no tema principal desta publicação, o Semantic Versioning (Versionamento Semântico).

Semantic Versioning

Basicamente, este um conjunto simples de regras e requisitos que ditam como os números das versões são atribuídos e incrementados, criado por Tom Preston-Werner. Provavelmente no seu dia-a-dia como desenvolvedor, você já deve ter visto em alguma linguagem de programação, biblioteca e/ou framework uma sequência de números assim:

Python 3.8.0
Django 2.2.7
Node.js 13.0.1
React 16.11.0

E eu me arrisco a afirmar que você saiba que essa sequência de números corresponde a uma versão específica de um software. Porém, você sabe qual é a lógica por trás desses números?

Como o próprio criador dessa especificação diz em seu paper, que você pode ler na íntegra clicando aqui, esta não é uma ideia nova ou revolucionária. De fato, você provavelmente já faz algo próximo a isso. O problema é que “próximo” não é bom o suficiente. Sem a aderência a algum tipo de especificação formal, os números de versão são essencialmente inúteis para gerenciamento de dependências.

Contudo, antes de entrarmos na real especificação do Semantic Versioning, um adendo interessante é que Tom Preston-Werner definiu algumas palavras chaves para melhor aderência ao princípio:

“As palavras-chaves “DEVE”, “NÃO DEVE”, “OBRIGATÓRIO”, “DEVERÁ”, “NÃO DEVERÁ”, “PODEM”, “NÃO PODEM”, “RECOMENDADO”, “PODE” e “OPCIONAL” no presente documento devem ser interpretados como descrito na RFC 2119.”

Enfim, sem mais delongas, vamos partir para a especificação, distribuída sob a licença Creative Commons - CC BY 3.0, na qual é definida em 11 regras básicas:

“Software usando Versionamento Semântico DEVE declarar uma API pública. Esta API poderá ser declarada no próprio código ou existir estritamente na documentação, desde que seja precisa e compreensiva.”

PS: É interessante salientar que “API pública” pode representar várias coisas, como: Classes, métodos e funções disponibilizadas por uma biblioteca, endpoints de uma API RESTful, endpoints de microserviços, etc.

“Um número de versão normal DEVE ter o formato de X.Y.Z, onde X, Y, e Z são inteiros não negativos, e NÃO DEVE conter zeros à esquerda. X é a versão Maior, Y é a versão Menor, e Z é a versão de Correção. Cada elemento DEVE aumentar numericamente. Por exemplo: 1.9.0 -> 1.10.0 -> 1.11.0.”
“Uma vez que um pacote versionado foi lançado (released), o conteúdo desta versão NÃO DEVE ser modificado. Qualquer modificação DEVE ser lançado como uma nova versão.”
“No início do desenvolvimento, a versão Maior DEVE ser zero (0.y.z). Qualquer coisa pode mudar a qualquer momento. A API pública não deve ser considerada estável.”
“Versão 1.0.0 define a API como pública. A maneira como o número de versão é incrementado após este lançamento é dependente da API pública e como ela muda.”
“Versão de Correção Z (x.y.Z | x > 0) DEVE ser incrementado apenas se mantiver compatibilidade e introduzir correção de bugs. Uma correção de bug é definida como uma mudança interna que corrige um comportamento incorreto.”
“Versão Menor Y (x.Y.z | x > 0) DEVE ser incrementada se uma funcionalidade nova e compatível for introduzida na API pública. DEVE ser incrementada se qualquer funcionalidade da API pública for definida como descontinuada. PODE ser incrementada se uma nova funcionalidade ou melhoria substancial for introduzida dentro do código privado. PODE incluir mudanças a nível de correção. A versão de Correção deve ser redefinida para 0(zero) quando a versão Menor for incrementada.”
“Versão Maior X (X.y.z | X > 0) DEVE ser incrementada se forem introduzidas mudanças incompatíveis na API pública. PODE incluir alterações a nível de versão Menor e de versão de Correção. Versão de Correção e Versão Menor devem ser redefinidas para 0 (zero) quando a versão Maior for incrementada.”
“Uma versão de Pré-Lançamento (pre-release) PODE ser identificada adicionando um hífen (dash) e uma série de identificadores separados por ponto (dot) imediatamente após a versão de Correção. Identificador DEVE incluir apenas caracteres alfanuméricos e hífen [0-9A-Za-z-]. Identificador NÃO DEVE ser vazio. Indicador numérico NÃO DEVE incluir zeros à esquerda. Versão de Pré-Lançamento tem precedência inferior à versão normal a que está associada. Uma versão de Pré-Lançamento (pre-release) indica que a versão é instável e pode não satisfazer os requisitos de compatibilidade pretendidos, como indicado por sua versão normal associada. Exemplos: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.”
“Metadados de construção (Build) PODE ser identificada por adicionar um sinal de adição (+) e uma série de identificadores separados por ponto imediatamente após a Correção ou Pré-Lançamento. Identificador DEVE ser composto apenas por caracteres alfanuméricos e hífen [0-9A-Za-z-]. Identificador NÃO DEVE ser vazio. Metadados de construção PODEM ser ignorados quando se determina a versão de precedência. Assim, duas versões que diferem apenas nos metadados de construção, têm a mesma precedência. Exemplos: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.”
“A precedência refere como as versões são comparadas com cada outra quando solicitado. A precedência DEVE ser calculada separando identificadores de versão em Maior, Menor, Correção e Pré-lançamento, nesta ordem (Metadados de construção não figuram na precedência). A precedência é determinada pela primeira diferença quando se compara cada identificador da esquerda para direita, como se segue: Versões Maior, Menor e Correção são sempre comparadas numericamente. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. Quando Maior, Menor e Correção são iguais, a versão de Pré-Lançamento tem precedência menor que a versão normal. Example: 1.0.0-alpha < 1.0.0. A precedência entre duas versões de Pré-lançamento com mesma versão Maior, Menor e Correção DEVE ser determinada comparando cada identificador separado por ponto da esquerda para direita até que seja encontrada diferença da seguinte forma: identificadores consistindo apenas dígitos são comparados numericamente e identificadores com letras ou hífen são comparados lexicalmente na ordem de classificação ASCII. Identificadores numéricos sempre têm menor precedência do que os não numéricos. Um conjunto maior de campos de pré-lançamento tem uma precedência maior do que um conjunto menor, se todos os identificadores anteriores são iguais. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.”

Conclusão

Eu poderia finalizar essa postagem com minhas próprias palavras sobre o Semantic Versioning, mas depois de ler esse trecho, tenho certeza que não conseguiria achar que superasse essa colocação:

“Como um desenvolvedor responsável você irá, é claro, querer certificar-se que qualquer atualização no pacote funcionará como anunciado. O mundo real é um lugar bagunçado; não há nada que possamos fazer quanto a isso senão sermos vigilantes. O que você pode fazer é deixar o Versionamento Semântico lhe fornecer uma maneira sensata de lançar e atualizar pacotes sem precisar atualizar para novas versões de pacotes dependentes, salvando-lhe tempo e aborrecimento.”

Caso você esteja interessado em saber mais sobre essa especificação, na qual na minha humilde opinião está muito bem definida e clara, sugiro que você leia ela na íntegra clicando aqui.

Se você assim como eu também está nessa jornada de aprendizado, sugiro também que você pesquise sobre outros tipos de versionamentos (Qual a diferença entre eles? Qual é mais interessante usar? Essas perguntas você só vai conseguir responder após ler sobre).

Tenho certeza que caso você esteja vendo essa publicação e chegou até aqui, é porque você e eu temos um desejo em comum, o de nos tornarmos desenvolvedores MUITO melhores.

Obrigado pela leitura e até a próxima! 😉

DRY, YAGNI e KISS

Mauro de Carvalho — Sat, 13 Nov 2021 01:57:29 +0000

Introdução

Essa é a segunda postagem correspondente à minha jornada para ser um desenvolvedor melhor. Novamente, gostaria de deixar claro que estou seguindo o excelentíssimo Web Developer Roadmap 2021, criado por Kamran Ahmed, como base para os meus estudos. Caso você queira ler a a minha primeira postagem, na qual eu resumi um pouco sobre o SOLID, clique aqui.

Enfim, vamos falar um pouquinho sobre DRY, YAGNI e KISS!!

DRY (Don’t Repeat Yourself — Não se repita)

“De tanto voltar ao seu ponto de partida, percebi que o poço profundo criado pela repetição transformou-se em mina de lamentações.” — Balsa Melo

A definição formal desse princípio, cunhada por Andy Hunt e Dave Thomas no excelentíssimo “O Programador Pragmático: de aprendiz a mestre”, diz que:

“Cada parte do conhecimento deve ter uma representação única, não ambígua e definitiva dentro do sistema.”

Contudo, não se engane em achar que este princípio se trata apenas de “não tenha código duplicado”, ele vai muito além disso. O próprio Andy Hunt enfatizou em uma discussão no wiki do repositório de padrões de Portland, o seguinte:

“A duplicação e a possibilidade de contradições podem surgir em qualquer lugar: na arquitetura, em requisitos, código e até mesmo na documentação. Os efeitos podem variar desde falhas de implementação de código, à confusão dos desenvolvedores; até a falha completa do sistema.”

Mas é claro, por mais que o conceito por trás do DRY seja bastante amplo, ainda assim vale falarmos um pouco do efeito da não aplicação desse princípio em nossos códigos:

Aumento da possibilidade de bugs, já que quando alguma mudança ocorre no sistema, talvez não tenhamos a garantia de que todas as instâncias repetidas também serão atualizadas;
A duplicação também pode gerar um aumento no tempo e esforço gasto na realização de manutenções, dificultar refatorações e criar possíveis contradições lógicas;
Dependendo da linguagem, pode acarretar até em problemas no desempenho da aplicação;

Uma última ressalva, é que caso seus testes, builds e deploys ainda sejam manuais, repetitivos e custosos em termos de tempo e esforço, talvez seja a hora de você pensar um pouco em automação. Duplicação na lógica deve ser eliminada via abstração; a duplicação no processo deve ser eliminada via automação.

YAGNI (You Aren’t Gonna Need It — Você não vai precisar disso)

“Tudo é caro demais quando não é necessário.” — James Joyce

YAGNI é um mantra pregado pelo eXtreme Programming (XP), onde resumidamente se diz que não devemos adicionar novas funcionalidades ao software a não ser que realmente seja necessário. Evitando essas “previsões”, você economiza tempo, pois evitará escrever código que não vai precisar no momento, e também, deixa seu código limpo, pois evitará poluir ele com “palpites” que acabam, na maioria das vezes, dificultando o entendimento do mesmo.

Contudo, uma ressalva foi feita pelo todo-poderoso Martin Fowler em uma excelente publicação sobre o YAGNI, na qual ele diz:

“Agora entendemos por que o YAGNI é importante, podemos ‘cavar’ uma confusão comum sobre o ele. Esse princípio se aplica apenas aos recursos incorporados ao software para oferecer suporte a um recurso presuntivo; não se aplica ao esforço para facilitar a modificação do software. YAGNI é apenas uma estratégia viável se o código for fácil de alterar, portanto, gastar esforços na refatoração não é uma violação deste princípio porque a refatoração torna o código mais maleável.”

KISS (Keep It Simple, Stupid — Mantenha simples, estúpido)

“A simplicidade é o último grau de sofisticação” — Leonardo Da Vinci

Um dos meus professores durante a minha graduação me agraciou com uma excelente definição sobre esse princípio. Em uma de suas aulas ele disse que o acrônimo KISS significava Kids In Satan’s Service (Crianças a serviço de Satanás), porquê códigos mal escritos, e consequentemente, difíceis de entender, com certeza eram feitos por algum novato/principiante a mando de Satã (Risos). É claro, por mais que essa seja uma definição deveras cômica, ela ainda não nos trás a real essência desse princípio, que é basicamente, ser simples. Toda e qualquer complexidade desnecessária em um projeto, independente da área, deve ser descartada.

O princípio KISS é usado em um variedade de campos, como design de produto, design de interface, propaganda, desenvolvimento de software, etc. Mas o que pouca gente sabe é que este termo foi utilizado pela primeira vez na Marinha dos EUA, cuja a autoria foi creditada a Kelly Johnson, que era o engenheiro principal no Lockheed Skunk Works. Johnson disse o seguinte aos projetistas da Lockheed:

“Designs devem ser simples o suficiente para serem reparados por um homem em uma situação de combate com apenas alguns treinamentos mecânicos básicos e ferramentas simples.”

Você provavelmente consegue assimilar essa situação descrita por Kelly Johnson com um prazo de entrega curto e um chefe bastante rigoroso. Pois é, meu amigo.. Mantenha as coisas simples.

Conclusão

DRY, YAGNI e KISS são três principios essenciais para qualquer desenvolvedor, e me atrevo a dizer que talvez você consiga aplicá-los até mesmo em outras situações da sua vida, é claro, usando o bom senso.

Essa postagem é um resumão sobre os meus estudos acerca desses princípios, o que vem a ser, talvez, até um pouco superficial demais, caso você esteja querendo se aprofundar nesses temas. Por isso, recomendo que você continue seus estudos, continue procurando conteúdo sobre esses princípios, porque eu tenho certeza que dominá-los e aplicá-los em sua profissão farão de você um desenvolvedor MUITO melhor.

Obrigado pela leitura e até a próxima! 😉

SOLID

Mauro de Carvalho — Sat, 13 Nov 2021 00:03:15 +0000

Introdução

Recentemente estava buscando ampliar um pouco o meu conhecimento no desenvolvimento back-end, e me deparei com um projeto super legal chamado Web Developer Roadmap 2021, criado por Kamran Ahmed. Basicamente, este estipula alguns “caminhos” a se seguir para você iniciar/melhorar o seu conhecimento acerca do desenvolvimento front-end, back-end e devOps. Vale a pena dar uma conferida se você, assim como eu, tem uma certa dificuldade, dada a grande variedade de tecnologias existentes, de saber onde focar seus estudos.

Na introdução deste roadmap, existe uma lista de noções/tecnologias/metodologias a serem entendidas independente do caminho que você for seguir. Alguns deles eu já domino, como Git, uso básico do terminal, estruturas de dados e licenças. Porém, ainda não me sinto confortável com os demais “requisitos” listados nesta introdução, por isso, irei documentar aqui no Dev.to um pouco dos meus estudos acerca deles.

Vale ressaltar que talvez essa publicação não seja o suficiente para você se aprofundar no tema-chave (indicado pelo título). Porém, ainda assim vale a leitura, já que talvez a minha visão possa agregar um pouco nos seus conhecimentos em relação ao assunto. Então sem mais delongas, vamos iniciar o nosso assunto sobre SOLID!

O que é?

Basicamente, SOLID é um acrônimo criado por Michael Feathers para cinco princípios de design na programação orientada a objetos, com o intuito de criar projetos de software mais compreensíveis, flexíveis e manuteníveis. São eles:

Single Responsibility Principle - SRP (Princípio da responsabilidade única)
Open Closed Principle - OCP (Princípio do aberto/fechado)
Liskov Substitution Principle - LSP (Princípio da substituição de Liskov)
Interface Segregation Principle - ISP (Princípio da segregação de interfaces)
Dependency Inversion Principle - DIP (Princípio da inversão de dependência)

O primeiro princípio: SRP

“uma classe deve ter apenas uma única responsabilidade.”

A descrição mais clara e formal deste princípio diz que a classe deve ter uma, e apenas uma, razão para mudar. Em outras palavras, poderíamos dizer que uma classe deve ser especializada em um único objetivo dentro do software, ou seja, ela deve executar/desempenhar uma única tarefa/ação.

O segundo princípio: OCP

"entidades de software devem ser abertas para extensão, mas fechadas para modificação."

Em resumo, para termos classes ainda mais coesas e de fácil evolução, elas devem ser modeladas de modo que quando houver mudanças nas regras de negócios, que não haja a necessidade de alteração no código original, mas sim que o comportamento deste possa ser estendido com facilidade.

O terceiro princípio: LSP

“objetos em um programa devem ser substituíveis por instâncias de seus subtipos, sem alterar a funcionalidade do programa.”

O princípio de substituição de Liskov leva esse nome por ter sido criado por Barbara Liskov que introduziu este conceito em uma conferência em 1987 e, posteriormente, em 1994 no artigo Family Values: A behavioral Notion of Subtyping juntamente com Jeannette Wing. A definição original desse princípio, de forma resumida, é a seguinte:

Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.

Em outras palavras, toda e qualquer classe derivada deve poder ser usada como se fosse a classe base. Este princípio tem algo bem parecido com a metodologia do projeto por contrato:

Precondições não podem ser reforçadas em uma sub-classe. Isto significa que não é permitida uma sub-classe com precondições mais fortes que a sua super-classe;
Pós-condições não podem ser enfraquecidas em uma sub-classe. Isto significa que não é permitida uma sub-classe que contém condições posteriores mais fracas que a super-classe.

O quarto princípio: ISP

“muitas interfaces de clientes específicas, são melhores do que uma para todos propósitos.”

Esse é um princípio um pouco mais simples que os anteriores. Em resumo, basicamente ele diz que é melhor criar interfaces mais específicas ao invés de uma única interface genérica. Uma classe não deve ser forçada a implementar interfaces e métodos que não irão utilizar.

O quinto princípio: DIP

“deve-se depender de abstrações, não de objetos concretos.”

De acordo com Robert Martin (Uncle Bob), este princípio pode ser definido da seguinte forma:

Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração;
Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

Abstrações tendem a ser estáveis, já as implementações, instáveis. Caso uma classe qualquer precise depender de outro módulo, seria interessante que esta seja uma abstração. Tente ao máximo não depender de outras implementações.

PS: Não confunda Inversão de dependência com Injeção de dependência. São duas coisas diferentes.

Conclusão

Como dito anteriormente, esse é um resumo bem superficial e talvez não seja o suficiente para você se aprofundar no assunto. Contudo, deixo aqui a recomendação de um livro muito bom que abriu muito a minha mente sobre SOLID:

Orientação a Objetos e SOLID para Ninjas - Projetando classes flexíveis, de Mauricio Aniche. Você pode adquirir esse livro clicando aqui.

Obrigado pela leitura e até a próxima! ;)

O que é o Git?

Mauro de Carvalho — Mon, 13 Sep 2021 01:53:57 +0000

Imagem de u3a.org.uk

Introdução

Se você já se aventurou um pouco no mundo do desenvolvimento, muito provavelmente você se deparou em alguns assuntos envolvendo o famoso “Git”. A internet está cheia de conteúdos relacionados a essa tecnologia nos mais diversos níveis. Algo bastante engraçado sobre o assunto, é que mesmo com anos de experiência na área de desenvolvimento de software, conheço alguns programadores (eu inclusive) que ainda se surpreendem com algumas funcionalidades e versatilidades que o Git oferece.

Git é uma tecnologia muito poderosa, e com toda certeza, foi um dos pilares para chegarmos ao nível de desenvolvimento de software moderno e de colaboração que temos hoje.

Estive um tempo sem escrever nada, então decidi criar essa postagem para, além de falar sobre o Git, poder desenferrujar um pouquinho. Prometo que vou tentar trazer alguns conteúdos interessantes para não termos “mais do mesmo”, já que, enfatizando novamente, o Git é um assunto bastante abordado na área de desenvolvimento de sistemas na internet.

Como de praxê: sem mais delongas, vamos começar!

O que é o Git?

Acho que a primeira coisa que precisamos deixar claro seria: “o que danado é esse tal de Git?!”.

Imagem de git-scm

De forma bastante resumida, Git é um sistema de controle de arquivos / versões distribuída. “Nossa Mauro, você ajudou bastante.. Acabou com todas as minhas dúvidas.. Uau”. Certo, certo, peço perdão. Sei que isso ainda não diz muita coisa, mas peço mais uma chance para continuarmos a explicação.

Imagine que você e um amigo precisassem alterar um mesmo arquivo de código simultaneamente, só que cada um em sua própria máquina. Depois de um tempo de trabalho, vocês teriam finalizado o desenvolvimento e iriam precisar “juntar” suas modificações. Muito provavelmente vocês teriam que se reunir e concatenar, em um outro arquivo, as modificações de ambos fizeram: “Ah, eu alterei isso, adiciona esse trecho, remove essa linha aqui, não esquece de importar essa biblitoeca, blá, blá, blá”.

Agora, até pra deixar as coisas mais interessantes, imagine que foram MUITAS alterações, em DIVERSOS arquivos de códigos, e que ao invés de ser você e seu amigo, fossem VÁRIOS desenvolvedores DIFERENTES e que todas as alterações precisassem entrar em vigor RÁPIDO, e pra piorar, que de alguma forma precisasse haver um histórico de TUDO que foi alterado. Baita trabalhão gerenciar isso, né? E é exatamente aqui que o Git entra.

O Git é uma tecnologia que permite que diversas pessoas possam contribuir no código fonte de um sistema simultaneamente. Não importa se seja criando, editando ou até apagando arquivos. O intuito da tecnologia é que não haja um descontrole nas alterações que estão sendo feitas.

Basicamente, o Git nos ajuda a criar e gerenciar versões do sistema que estamos trabalhando, nos dando toda a garantia de integridade para mantermos a consistência do mesmo.

Um pouquinho de história...

Sempre que eu vou estudar alguma tecnologia ou metodologia nova, gosto bastante de pesquisar como que os problemas relacionados a elas eram resolvidos antes. Heródoto, famoso historiador grego, disse uma vez: “Pensar o passado para compreender o presente e idealizar o futuro”. Na minha concepção, essa frase faz muito sentido para nossa construção como desenvolvedores melhores. É muito engraçado como esse tipo de conhecimento desperta em mim uma sensação de gratidão e vontade de colaborar mais para o crescimento da nossa área (ai ai, *suspiro*). Enfim, vamos ao que interessa, né? Como surgiu o Git?!

Antes de mais nada, precisamos citar um dos nomes mais conhecidos no mundo da computação que é o Linus Torvalds. Caso você não saiba quem é esse cara (tsc tsc tsc), resumidamente, ele é apenas o criador do Linux. Mas como se não bastasse, adivinhe só? Esse bendito também é, por sinal, o criador do Git! Como diria Vegeta de Dragon Ball Z: "O miserável é um gênio". Brincadeiras a parte, um ponto muito interessante a se ressaltar aqui é que a história da criação do Git está totalmente atrelada a história do desenvolvimento do Linux.

Linus Torvalds, Imagem de Insider

Como você deve imaginar, o projeto do Linux é algo com o escopo bastante grande. Muito código, muitas melhorias, muita manutenção, muitos desenvolvedores. Mega trabalhão organizar e gerenciar isso tudo, né?

Em 2002, o projeto do Linux começou usar um Sistema de Controle de Versão Distribuida (mais comumente achada na literatura como Distributed version control system, ou apenas DVCS) chamada "BitKeeper". Só pra constar, sucintamente, um DVCS é uma forma de controle de versão em que a base de código inteira, incluindo seu histórico completo, é "espelhada" no computador de cada desenvolvedor. De fato, dá pra ter noção de como essa tecnologia era uma mão na roda para o time de desenvolvimento do Linux na época.

Logo da Bitkeeper, Imagem de Wikimedia Commons

O Bitkeeper, até então, era um software proprietário, ou seja, a licença de sua utilização era paga. Por um tempo, entretanto, a BitMoover (empresa criadora do Bitkeeper) permitiu que uma versão gratuita fosse utilizada pelo time de desenvolvedores do Linux e também por toda comunidade de desenvolvedores no mundo.

Mas como toda boa história por trás do universo da computação não pode deixar de ter uma boa e velha "treta", nos meados de 2005, a BitMoover acusou o time de desenvolvimento do Linux de violação de licença e engenharia reversa, dado que um dos seus membros (Andrew Tridgell, criador do SAMBA), na época, acabou desenvolvendo um client open source ao qual permitia que se pudesse trabalhar com o alguns metadados do BitKeeper. Por conta disso, a BitMoover acabou suspendendo a utilização gratuita do Bitkeeper para a comunidade e também se recusou a vender licenças para a Open Source Development Labs (OSDL), organização responsável pela aceleração do desenvolvimento do Linux, ao qual Linus Torvalds e Andrew Tridgell faziam parte. E foi com base nesse clima super tranquilo que iniciou-se o desenvolvimento do Git.

Andrew Tridgell, Imagem de State of Eletronics

Linus Torvalds e toda equipe de desenvolvimento do Linux pesquisaram durante bastante tempo por algo que pudesse substituir o BitKeeper. Contudo, as soluções oferecidas naquele tempo eram bem limitadas e não atendiam as necessidades que eles buscavam. Seguindo essa linha, "já que não tem nada parecido, por que não criar a nossa própria?". Foi então que Linux Torvalds se propôs a criar algo que não apenas substituisse o Bitkeeper, mas que fosse superior! Desde então, algumas metas que o novo sistema deveria seguir eram as seguintes:

Open Source;
distribuida;
rápida;
design simples;
ter suporte para desenvolvimento não-linear;
e ser capaz de lidar com grandes projetos.

E BOOMM!! Assim surgiu o Git! Inicialmente, todos os requisitos pontuados, e o real intuito da criação do Git, visavam resolver apenas os problemas relacionados ao desenvolvimento do Linux. Mas o projeto escalou tão bem que acabou caindo nas graças da comunidade, e hoje, nem precisa falar que é um conhecimento/ferramenta indispensável no dia-a-dia de um programador.

Onde aprender?

Como eu disse no começo desta postagem, Git é uma ferramenta tão versátil e completa, que até mesmo após anos de desenvolvimento, vira e mexe a gente aprende algo novo. A internet está CHEIA de informações sobre como aprender Git, contudo, muitas delas bastantes superficiais. Os melhores conteúdos sobre Git geralmente são disponibilizados em inglês, mas mesmo assim consegui encontrar um excelente conteúdo em português também! Abaixo segue uma listinha seleta com bons cursos nível "zero to hero" para você aprender Git de uma vez por todas:

Considerações Finais

Durante seus estudos, você vai se deparar com algumas ferramentas que facilitam o trabalho com o Git, como Git Kraken ou Sourcetree. Por "facilitar", não pense que o Git é uma ferramenta difícil de trabalhar, ao contrário, ela é muito simples. Porém, alguns fluxos de trabalho acabam se tornando um pouco "corriqueiros demais" com o passar do tempo, fazendo com que muitas vezes desenvolvedores cogitem usar esses utilitários. Contudo, uma dica que eu posso te dar é não utilizá-las se você estiver começando a aprender/trabalhar com Git. Elas são muito boas, não há como negar, mas o fato delas abstrairem alguns pontos importantes de conhecimento (noções de commit, pull/push, merge, rebase, stash, resolução de conflitos, cherry-pick, etc) acabam privando você de compreender a magnitude por trás do Git. Quando você estiver bastante experiente, com conhecimentos consolidados e não quiser "perder tempo", fica aí algumas dicas de ferramentas:

E chegamos ao fim de mais um artigo! Agradeço pela leitura e paciência até aqui, e espero ter contribuido um pouquinho pro seu conhecimento. Se você tiver artigos e conteúdos interessantes sobre Git, sinta-se a vontade de comentar aqui, vai ser de grande ajuda! Valeu, pessoal! Até a próxima. :-)