DEV Community: Natália Oliveira

Resumindo características da linguagem Python

Natália Oliveira — Mon, 03 Mar 2025 19:18:43 +0000

Python é uma linguagem de propósito geral, multiparadigma, de alto nível, de tipagem dinâmica, fortemente tipada, que roda em diferentes plataformas e é interpretada (com um passo de compilação). Vamos destrinchar esses conceitos utilizando principalmente o livro "Python in a Nutshell", documentações da linguagem e as aulas incríveis do Eduardo Mendes.

Propósito geral e alto nível
Tipagem dinâmica e forte
Linguagem intepretada com um passo de compilação
Roda em diferentes plataformas

Propósito geral e alto nível

Consideramos Python como de propósito geral pois suas características são úteis para diversas áreas de software. Iremos encontrar Python em REST APIs, scripts, machine learning, análises estatísticas, web scraping, etc. Python já era bastante utilizada na área de inteligência artificial e, com o boom dos LLMs, me parece que muitas áreas tornamram a linguagem como o padrão de uso. Se procurarmos por vagas de machine learning engineer, data engineer e por aí vai é muito comum encontrar o Python como requisito.

A consideramos como de alto nível por possuir um alto nível de abstração, se afastando bastante da linguagem de máquina que um computador de fato entende. Além disso, a linguagem é bem "parecida" com uma leitura em inglês, o que é muito atrativo. Outros exemplos de linguagens de alto nível são Java, JavaScript, entre outras.

Tipagem dinâmica e forte

Acredito que esse tópico gere uma certa dúvida. Eu particularmente precisei revisitar esses conceitos diversas vezes até entender. O Python tem tipagem dinâmica, ou seja, não te obriga a declarar o tipo de uma variável, você pode declarar um a = "texto" e o interpretador, por debaixo dos panos, vai inferir que a variável é do tipo string. Ao mesmo tempo, é fortemente tipada, pois o interpretador mantém controle dos tipos de variáveis que estão sendo declaradas no programa, coisa que não acontece numa linguagem fracamente tipada como o JavaScript, por exemplo. No JavaScript você pode fazer 'x' + 3 resultar em 'x3' e não dará erro; se você tentar fazer isso em Python verá:

TypeError: can only concatenate str (not "int") to str

Sobre ser dinamicamente tipada e fortemente tipada ao mesmo tempo, vejamos esse excerto do Wiki do Python:

Python é fortemente tipado, pois o interpretador mantém o controle de todos os tipos de variáveis. Ele também é muito dinâmico, pois raramente usa o que sabe para limitar o uso de variáveis. Em Python, é responsabilidade do programa usar funções internas como isinstance() e issubclass() para testar tipos de variáveis e uso correto. Python tenta ficar fora do seu caminho enquanto fornece tudo o que você precisa para implementar a verificação de tipo forte.

Falando em "Python tenta ficar fora do seu caminho enquanto fornece tudo o que você precisa para implementar a verificação de tipo forte", pegamos o gancho para falar de "type hints" ou "type annotations". Type annotations são uma feature mais "recente" (PEP 484 de de 2014) do Python que nos permite "anotar" o tipo de dado que estamos lidando no código. Do livro "Python in a Nutshell":

Anotar seu código Python com informações de tipo é uma etapa opcional que pode ser muito útil durante o desenvolvimento e a manutenção de um projeto grande ou de uma biblioteca. Verificadores de tipo estático e ferramentas lint ajudam a identificar e localizar incompatibilidades de tipo de dados em argumentos de função e valores de retorno. IDEs podem usar essas anotações de tipo (também chamadas de dicas de tipo) para melhorar o preenchimento automático e fornecer documentação pop-up. Pacotes e frameworks de terceiros podem usar anotações de tipo para personalizar o comportamento do tempo de execução ou para gerar automaticamente código com base em anotações de tipo para métodos e variáveis.

É daí que temos libs como mypy e Pydantic para checar e validar tipos.

Linguagem intepretada com um passo de compilação

O Python é considerado interpretado com um passo de compilação: uma linguagem ser interpretada significa que ela não é executada diretamente pela máquina, e sim é interpretada e executada por outro programa. Aqui temos um catch que confunde bastante, pois na real o CPython, que é o interpretador referência da linguagem, é um compilador de
bytecode e também interpretador: ele compila o código Python e, com o resultado dessa compilação (que chamamos de bytecode ou intermediary language), roda esse resultado diretamente em uma máquina virtual. Recomendo fortemente a aula do Eduardo Mendes
sobre isso:

Aí você pode ser perguntar:

Mas qual a diferença entre esse processo e um processo de compilação de um linguagem como Java?

Para ficar mais claro, veja que em uma linguagem 100% compilada a linguagem intermediária é transformada para linguagem de máquina, para então ser rodada pelo computador de fato. Para ilustrar um pouco melhor esse processo acompanhe esse slide da aula do Eduardo Mendes:

Roda em diferentes plataformas

Se você viu essa afirmação em algum lugar, perceba que isso é dito pois você pode escrever e rodar um programa Python em qualquer computador moderno que tenha Python instalado. "Instalar" significa ter o interpretador Python para rodar a linguagem. Em computadores com sistema operacional baseado em Unix, como Linux e MacOS, é comum que o interpretador Python já esteja instalado em alguma versão. No caso de Windows, até onde sei, você precisa ir lá no site no Python, baixar e instalar o interpretador.

Fontes:

Python in a Nutshell

Why is Python a dynamic language and also a strongly typed language

StackOverflow Compiled vs. Interpreted Languages

Como o interpretador do Python funciona? Live de Python #218

Leituras técnicas de 2024

Natália Oliveira — Wed, 29 Jan 2025 12:44:37 +0000

Texto originalmente publicado aqui.

Faz algum tempo que comecei a perceber minha falta de paciência para prestar atenção em conteúdos escritos, coisa que não acontecia antes. Acredito que fiquei mal acostumada a buscar informações em vídeo e, quanto mais avanço na área, mais percebo que conteúdos
escritos às vezes são a única fonte de informação para determinados assuntos. Com isso, no início de 2024, me propus a ler mais livros, para:

Fortalecer o foco e forçar a atenção em conteúdos mais difíceis de se consumir;
Exercitar o "não" a conteúdos de rede social/de conteúdo (exemplo: antes de ir dormir, ler, ao invés de ficar olhando o celular);
Exercitar meu vocabulário (inglês e português);
Ter contato inicial com temas específicos;
Exercitar a reflexão.

Resolvi unir o últil ao agradável e separar alguns livros técnicos para ler durante o ano, por completo. Essas foram as leituras que fiz em 2024:

Designing Data-Intensive Applications
Artificial Intelligence Basics
Database Internals
Criando Microsserviços

E por fim separei algumas menções honrosas.

Designing Data-Intensive Applications

De longe o melhor que eu li no ano. É o tipo de livro para ser relido pelo menos umas 3 vezes, e isso é o que pretendo fazer. Foi graças a esse livro que consegui entender uma apresentação sobre um tema super complexo envolvendo escalabilidade em escrita de dados de um time no trabalho. É também uma excelente forma de revisão sobre sistemas distribuídos, assunto que geralmente é tratado na faculdade.

O autor, Martin Kleppmann, escreve muito bem e a leitura não é de um feeling pesado acadêmico, é algo simples de ler com vários exemplos de tecnologias usadas hoje em dia. Não é a toa que esse livro já vendeu muito e tem trocentos bons reviews em várias plataformas. Recomendo a leitura.

Obs.: tem uma nova edição desse livro no forno prevista para dezembro de 2025 e espero que essa edicão seja traduzida para o português.

Link para o livro Designing Data-Intensive Applications

Artificial Intelligence Basics

Fui de uma leitura bastante técnica e primorosa para um livro OK. Esse livro é bom para deixar a gente refletindo e ter algumas noções básicas sobre o assunto, mas não sei se é uma leitura útil para todas as pessoas da área tech. Para alguém de fora da área pode ser mais interessante. No meu caso foi últil para refletir sobre o assunto, apenas como leitura superficial mesmo, mas achei o último capítulo meio abaixo do resto. No geral, pessoalmente valeu a pena, por ser uma leitura leve e com alguns conceitos introdutórios.

Vale frisar que esse livro foi publicado em 2019, antes do hype de generative AI, então o autor, Tom Taulli, não estava apenas surfando a onda.

Se você é da área tech e quer ler algo profundo sobre AI, vá ler Norvig e Russell. Se quer colocar a mão na massa com algo atual, estou vendo bons reviews sobre Build a Large Language Model (from Scratch) do Sebastian Raschka.

Link para o livro Artificial Intelligence Basics

Database Internals

É um livro bastante enxuto para os conceitos que trata. Em outras palavras, leitura extremamente difícil para mim, pois me faltavam vários conhecimentos prévios para entender o livro. Exemplo: funcionamento da estrutura de dados b-tree. O livro é pequeno e demorei horrores para terminar, pois estava voltando alguns parágrafos, pesquisando artigos na internet e olhando vídeos no YouTube toda hora para consolidar o entendimento. Felizmente isso me fez encontrar canais bem legais no YouTube como o Spanning Tree, com uma explicação visual bem legal sobre b-trees.

Recomendo para pessoas curiosas, quem trabalha na área de dados, banco de dados, etc. Pode ser uma leitura útil e interessante, mas vai depender bastante da pessoa. No meu caso posso dizer que valeu a pena, mas definitivamente não foi uma leitura que posso considerar "agradável", já que fiquei empacando.

Link para o livro Database Internals

Criando Microsserviços

Livro de referência completa para microsserviços e creio que o livro por si só já tenha esse status, a julgar pelos reviews e pelas vezes que já vi sendo citado. A leitura foi bem fácil e fluida, não só pela escrita, mas pelo fato da maioria dos temas e tecnologias já fazerem parte do meu dia a dia, ou pelo menos já ouvi falar e está próximo de mim. Li a versão em português e notei alguns erros, além da sensação esquisita de ver alguns termos
traduzidos que eu só vejo em inglês no dia a dia, mas não foi nada que atrapalhasse a leitura.

Recomendo a leitura.

Link para o livro Construindo Microsserviços

Menções honrosas

Precisei ler alguns capítulos de uns livros para a pós-gradução, então não li estes por completo:

Cassandra The Definitive Guide: livro excelente e completo sobre o Apache Cassandra. Achei bem complexo entender o Cassandra e esse livro ajudou muito;
MongoDB The Definitive Guide: livro completinho sobre MongoDB, me ajudou não só com a parte teórica, mas também tirei várias dúvidas quando estava fazendo o projeto prático.

Infraestrutura para análise de dados com Jupyter, Cassandra, Pyspark e Docker

Natália Oliveira — Wed, 15 Jan 2025 10:47:46 +0000

Imagem retirada do site do Jupyter Notebooks

Texto originalmente publicado aqui.

Hoje vou mostrar como configurar um projeto para análise de dados com o Cassandra e o Jupyter Notebook com Pyspark, usando tudo no Docker. Vamos abordar:

Configurando o Apache Cassandra com Docker
O que é o Spark?
Configurando o Jupyter com Pyspark no Docker
Iniciando um sessão Spark conectada no Cassandra

Antes de começar, essa é a estrutura de pastas do projetinho:

cassandra-jupyter-spark-python
├── .gitignore
├── Makefile
├── README.md
├── data
│   └── csv-here.md
├── docker-compose.yml
├── jupyter
│   └── Untitled.ipynb
└── pyproject.toml

Você pode encontrar um projeto similiar a esse, completo, com análise de dados (porcamente feita por mim) no GitHub.

Configurando o Apache Cassandra com Docker

O Cassandra é um banco de dados NoSQL decentralizado, com escalabilidade elástica, altamente disponível, tolerante a falhas e orientado a linhas particionadas; escrevi um texto sobre o Cassandra aqui e você pode verificar a documentação do Cassandra aqui.

Para subir o Cassandra com Docker podemos fazer o seguinte:

services:
  cassandra1:
    image: cassandra:4.0.14
    container_name: cassandra1
    networks:
      - cassandra_network
    environment:
      - CASSANDRA_CLUSTER_NAME=cassandra_cluster
      - CASSANDRA_SEEDS=cassandra1
      - CASSANDRA_DC=datacenter1
      - CASSANDRA_RACK=rack1
      - CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch
    volumes:
      - ./data:/data
    ports:
      - "9042:9042"

No código acima estamos criando um node do Cassandra 4.0.14 (versão escolhida para evitar problemas de compatibilidade nesse projeto) numa rede Docker chamada cassandra_network. Explicando as variáveis de ambiente no environment:

CASSANDRA_CLUSTER_NAME: define o nome do cluster onde um ou mais nodes do Cassandra irão rodar. Cluster se refere a mais de uma máquina, geralmente para se referir a um sistema distribuído. No “docker-compose” do projeto chamamos de “cassandra_cluster”;
CASSANDRA_SEEDS: indica os serviços (ou IPs) usados pelo gossip do Cassandra, para adicionar novos nodes ao cluster. O gossip é um protocolo utilizado para manter informações sobre o status dos nodes no cluster, para dar suporte a descentralização e tolerância a particionamento;
CASSANDRA_DC: define o data center do node, que é um agrupamento lógico de racks. Não é necessário para rodar essa infraestrutura localmente em um notebook, como é o caso atual, mas seria utilizado caso estivéssemos utilizando o Cassandra com o uso adequado a que se propõe;
CASSANDRA_RACK: define o rack do node, que é um agrupamento lógico de nodes. Novamente, não é necessário para a situação atual, mas seria utilizado em um caso real;
CASSANDRA_ENDPOINT_SNITCH: define a implementação de snitch que esse node irá utilizar. O snitch provê informações sobre a topologia da rede onde o Cassandra está para redirecionar requisições de forma mais eficiente. Nesse caso aqui configuramos como “GossipingPropertyFileSnitch”, geralmente usado em produção, para considerar as informações de rack e datacenter.

O volume ./data:/data serve para que você coloque, por exemplo, arquivos .csv parte da sua análise de dados. No meu caso, criei um projeto para a pós-graduação, onde usei o comando COPY para repassar os dados tratados do .csv para o Cassandra.

Agora, criando um segundo node Cassandra:

cassandra2:
  image: cassandra:4.0.14
  container_name: cassandra2
  networks:
    - cassandra_network
  environment:
    - CASSANDRA_CLUSTER_NAME=cassandra_cluster
    - CASSANDRA_SEEDS=cassandra1
    - CASSANDRA_DC=datacenter1
    - CASSANDRA_RACK=rack1
    - CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch
  volumes:
    - ./data:/data
  ports:
    - "9043:9042"
  depends_on:
    - cassandra1

Você pode usar somente um node, já que está rodando em seu computador, mas vale lembrar que um node só perde o propósito de uso do Cassandra. Esse banco é feito para ter diversos nodes no cluster.

Veja que esse segundo node aponta os seeds para o outro node. Isso é para que o cassandra2 se conecte com o cassandra1, para descrobrir a topologia do cluster e se unir a esse cluster.

O que é o Spark?

O Apache Spark é uma engine para engenharia e análise de dados, ciência de dados e machine learning em larga escala, onde é possível rodar para máquinas com um único nó ou cluster. Podemos usar Python, SQL, Scala, Java e R para interagir com o Spark, e aqui nesse projeto usaremos Python, com Pyspark.

Usos do Spark, segundo sua documentação:

Batch/streaming: unifica o processamento dos dados em lotes e streaming em tempo real, usando Python, SQL, Scala, Java ou R
Análise de SQL: executa consultas ANSI SQL rápidas e distribuídas para painéis e relatórios ad-hoc
Ciência de dados em escala: executa Análise Exploratória de Dados (EDA) em dados em escala de petabytes sem precisar recorrer à redução de amostragem
Aprendizado de máquina: treine algoritmos de aprendizado de máquina em um laptop e use o mesmo código para escalar para clusters tolerantes a falhas de milhares de máquinas.

Configurando o Jupyter com Pyspark no Docker

O Jupyter é uma tecnologia para computação interativa onde usamos uma linguagem de programação para, geralmente, fazer análises de dados e experimentos do tipo. Para rodá-lo no Docker:

  # Docker Hub Image. Uses spark-3.5.0-bin-hadoop3
  jupyter_pyspark:
    image: jupyter/pyspark-notebook:latest
    container_name: juptyer_pyspark
    environment:
      JUPYTER_ENABLE_LAB: "yes"
    ports:
      - "8888:8888"
    networks:
      - cassandra_network
    volumes:
      - ./jupyter:/home/jovyan
    depends_on:
      - cassandra1

networks:
  cassandra_network:
    driver: bridge

Essa imagem do Jupyter já vem com o Spark, mas vale apontar que aqui estamos usando a imagem do Docker Hub, que não recebe atualizações e está parada no Spark 3.5.0 e Hadoop 3, e não da Quay, que recebe atualizações. Tive muitos problemas tentando manter a compatibilidade entre as ferramentas, e a imagem do Docker Hub funcionou para o propósito.

O volume, assim como nos cassandras, é para poder salvar os notebooks no host. O container está na mesma rede que os outros e o JUPYTER_ENABLE_LAB é para que a gente não precise fazer login ou usar token, bastará abrir o browser no http://localhost:8888:

Iniciando uma sessão Spark conectada no Cassandra

Com o docker-compose.yml finalizado, podemos rodar os containers:

docker compose up --build

No http://localhost:8888, abrindo um novo arquivo no Jupyter, vamos importar uma sessão Spark da lib pyspark:

from pyspark.sql import SparkSession

E configurar a sessão:

spark = SparkSession.builder.appName("test").config("spark.jars.packages", "com.datastax.spark:spark-cassandra-connector_2.12:3.5.0").config("spark.cassandra.connection.host", "cassandra1").config("spark.cassandra.connection.port", "9042").getOrCreate()

Muita atenção aqui nessa parte. O código acima está:

Iniciando uma sessão Spark
Criando um novo "app" (o projeto em si) chamado "test"
Configurando o Spark com um pacote jar, utilizando um conector de Spark para Cassandra
Conectando com o serviço Cassandra chamado cassandra1
Configurando a porta da conexão para o 9042, que é onde está nosso container
Criando a conexão

Note que estamos usando um conector específico:

spark-cassandra-connector_2.12:3.5.0

Podemos olhar essas versões no site do Maven, e aqui nesse ponto foi onde mais topei com erros, especialmente de compatibilidade.

Se tudo der certo no comando anterior, depois rode esse comando para ver a sessão
ativa:

spark.active()

Você verá algo assim:

Fontes:

Imagem Docker do Cassandra

Image Docker do Jupyter com Spark

Apache Spark

O que é o Apache Cassandra e quando usar?

Natália Oliveira — Wed, 08 Jan 2025 13:22:40 +0000

Texto originalmente publicado aqui.

Hoje falarei um pouco sobre o Apache Cassandra. Usei como base o livro Cassandra The Definitive Guide, bastante utilizado para entender sobre a tecnologia, e um pouco do já clássico Designing Data-Intensive Applications. Abordarei os seguintes tópicos:

O que é o Apache Cassandra?
"Row-oriented": o que isso significa?
Quando utilizar o Cassandra?

O que é o Apache Cassandra?

O Cassandra é um banco de dados NoSQL de código aberto, decentralizado, com escalabilidade elástica, altamente disponível, tolerante a falhas e orientado a linhas particionadas, onde os dados são armazenados em tabelas hash multidimensionais esparsas. Vamos discutir esses pontos.

Bancos NoSQL (not only SQL) são bancos que não seguem os padrões de bancos relacionais, resolvendo problemas um pouco diferentes (em breve farei um texto sobre isso), sendo mais flexíveis (ou totalmente livres) no quesito de schema (como os dados são organizados, restrições lógicas como nome de tabelas, campos e seus tipos, etc), também chamados de schemaless ou de schema on read (schema reforçado apenas na leitura, e não na escrita como os relacionais). No caso do Cassandra podemos dizer que atualmente ele possui um schema flexível.

O Cassandra é capaz de rodar em várias máquinas como um sistema só, por isso é considerado distribuído e foi feito pensando nisso. Faz pouco sentido rodar o Cassandra em um único nó (node).

Grande parte de seu design e base de código são projetados especificamente não apenas para funcionar em muitas máquinas diferentes, mas também para otimizar o desempenho em vários racks de data center e até mesmo para um único cluster Cassandra em execução em data centers geograficamente dispersos. (CARPENTER and HEWITT, 2022)

O Cassandra também é descentralizado porque cada node é idêntico, no sentido de que nenhum node realiza tarefas especializadas como operações de organização; em outras palavras, o Cassandra possui uma arquitetura peer-to-peer. Como nenhum
node é especializado podemos dizer que não há um único ponto de falha aqui (single point of failure).

Ser elasticamente escalável significa que o sistema pode continuar servindo para mais usuários sem degradar a performance, podendo escalar e desescalar perfeitamente, sem problemas.

A alta disponibilidade do Cassandra é devido a sua alta capacidade de atender requests. Isso está diretamente relacionado com teorema CAP: assumindo uma situação de partitioning, o Cassandra prioriza availability em detrimento de consistency. Entretanto, vale a pena esclarecer que a consistência no Cassandra é ajustável (tuneable consistency, é uma configuração). Em minhas leituras entendi que atualmente o CAP theorem é como knobs, como se pudéssemos ajustar um pouco mais uma ou outra configuração. Recomendo ler um pouco mais sobre o
teorema CAP no capítulo 9 do Designing Data Intensive Application.

"Row-oriented": o que isso significa?

Na pesquisa para fazer esse artigo e entender melhor o assunto encontrei informações discrepantes, o que me levou a crer que há muita confusão aqui e talvez seja bom evitar algumas fontes da internet. Felizmente estamos seguindo um livro base. Pela definição de Carpenter e Hewitt:

O modelo de dados do Cassandra pode ser descrito como um armazenamento de linha particionado, no qual os dados são armazenados em tabelas hash multidimensionais esparsas. “Esparso” significa que para qualquer linha dada você pode ter uma ou mais colunas, mas cada linha não precisa ter todas as mesmas colunas que outras linhas como ela (como em um modelo relacional). “Particionado” significa que cada linha tem uma chave de partição exclusiva usada para distribuir as linhas em vários armazenamentos de dados. (CARPENTER and HEWITT, 2022)

Ou seja, quando for ter uma "imagem mental" dos dados no Cassandra faz sentido pensar numa linha de banco relacional, dadas as devidas diferenças: cada linha pode ter uma ou mais colunas e não precisa ter as mesmas colunas que outra linha, além de ter uma chave de partição única.

Sobre a confusão de termos que citei anteriormente, você pode ter visto o termo column oriented, mas o livro base desse texto aborda isso:

O Cassandra tem sido frequentemente chamado de banco de dados orientado a colunas ou colunar, mas isso não é tecnicamente correto. O erro é baseado na confusão entre termos que soam semelhantes. Um banco de dados orientado a colunas é aquele em que os dados são armazenados por colunas, ao contrário de bancos de dados relacionais, que armazenam dados em linhas (daí o termo orientado a linhas). Bancos de dados orientados a colunas, como Apache HBase ou Apache Kudu, são projetados para casos de uso analítico. (CARPENTER and HEWITT, 2022)

Quando utilizar o Cassandra?

O Cassandra pode ser um bom fit para o seu projeto caso você precise lidar com:

Grandes deployments: você precisa de muitos e muitos nodes para a sua aplicação, com a expectativa de escalar muito de forma fácil
Muita escrita, estatística e análise: sua aplicação precisa de muita estatística e muita escrita concorrent, com poucas leituras. Exemplos: pesquisa documentos, uso de redes sociais, recomendações/avaliações, etc
Distribuíção geográfica: o Cassandra tem suporte para distribuição geográfica de dados built in
Nuvem híbrida e deployment multicloud: você precisa fazer deploy não só em múltiplos data centers, mas também em provedores de cloud diferentes. Exemplo: você precisa da maior disponibilidade possível para um aplicativo mission critical e por isso utiliza mais de um proveador (se houver problemas com um provedor ainda haverá o outro)

Fontes:

CARPENTER, Jeff; HEWITT, Eben. Cassandra: The Difinitive Guide. O'Reilly, 2022.

KLEPPMANN, Martin. Designing Data-Intensive Applications. O'Reilly, 2017.

What is a database schema? por IBM

Resumo de conceitos de bancos de dados relacionais

Natália Oliveira — Mon, 06 Jan 2025 10:37:58 +0000

Texto originalmente publicado aqui.

Nesse texto irei abordar de forma resumida alguns conceitos (não é uma lista exaustiva!) que envolvem bancos de dados relacionais:

Transações (transactions)
ACID
Two-phase commit (2PC)
Schema
Sharding

Transações (transactions)?

Banco de dados relacionais suportam transações transactions), que são como uma unidade de operação completa num banco relacional, que executa primeiro "virtualmente" e permite que a operação seja desfeita (rollback) se qualquer modificação tenha dado errado. No caso de dar tudo certo com todos os passos da transação, ela pode ser comitada (commited) com segurança no banco.

Em outras palavras, uma transação pode ser compreendida como uma transformação de estado que possui as propriedades ACID.

ACID

ACID é um acrônimo para atômico, consistente, isolado e durável. Você pode encontrar a expressão ACID compliant para se referir a um banco que dê suporte a essas propriedades.

Atômico (atomicity): significa "tudo ou nada" em uma transação. Se uma transação é executada, todas as operações que ela contém precisam ser um sucesso. Ou todas as operações são um sucesso ou a transação falha (pense em OR exclusivo aqui).
Consitente (consistency): uma transação bem sucedida leva os dados de um estado consistente para outro, sem a possibilidade de usuários verem dados diferentes que não fazem sentido juntos.
Isolado (isolation): as transações que forem executadas concorrentemente não afetarão umas as outras. Ou seja, se uma transação tentar modificar os mesmos dados que outra, ela terá que esperar.
Durável (durable): uma transação bem sucedida não será perdida, por exemplo, caso ocorra algum desastre com o data center que contém o banco.

Two-phase commit (2PC)

Lidar com transações é um pouco mais difícil quando temos grandes cargas, com vários usuários realizando muitas operações no banco, e quando vamos escalar horizontalmente (adicionando mais máquinas e agora lidando com um sistema distribuído) para lidar com essa carga passamos a lidar também com transações distribuídas (distributed transactions). Com isso, para manter o banco com propriedades ACID, precisamos ter algum gerenciador de transações para conseguir orquestrar essas transações em vários nodes diferentes.

É aqui que entra a ideia de two-phase commit, que é um algortimo pensado para lidar com consenso entre nodes (máquinas) em um sistema distribuído. O 2PC possui duas fases, duas interações entre hosts: fase de preparação e fase de commit, as quais bloqueiam os recursos associados. Com esse lock (bloqueio) de recursos já podemos imaginar que algumas operações podem levar muito tempo para terminar.

Abaixo uma ilustração do livro Designing Data Intensive Application:

O 2PC espera um node responder, mesmo que o node já tenha morrido e, para não ter um loop rodando para sempre, esperando o node ficar vivo, podemos configurar um timeout. Ainda assim é possivel que ocorra um loop infinito pois um node pode responder OK para commitar a transação, esperar o gerenciador (coordenador) de
transações e, se o coordenador está down, o node vai esperar para sempre. Para lidar com esse tipo de problema no mundo relacional temos a ideia de compensation, onde a transação é imediatamente comitada, e no caso de um erro ser reportado, uma nova operação é feita para retificar o estado.

Alguns problemas que o 2PC introduz:

Perda de disponibilidade (availability)
Maior latência (tempo para chegar de um ponto a outro na rede) em falhas parciais

Para manter o banco relacional ACID compliant é necessário levar em consideração esses problemas que surgem no cenário de um sistema distribuído.

Schema

Você pode representar seus objetos de domínio em um modelo relacional, onde temos entidades e relacionamentos. Geralmente nos referimos ao modelo relacional como schema on write, em contraste com o schema on read de bancos NoSQL, que são mais flexíveis. Schema on write é a característica de ter um schema mais rígido que é reforçado na hora da escrita no banco:

As bases de dados relacionais assumem frequentemente que todos os dados na base de dados estão em conformidade com um esquema: embora este esquema possa ser alterado (através de migrações de esquemas; ou seja, instruções ALTER), existe exatamente um esquema em vigor. Por outro lado, as bases de dados schema-on-read (“sem esquema”) não impõem um esquema, então a base de dados pode conter uma mistura de formatos de dados mais antigos e mais recentes escritos em diferentes momentos(...) (KLEPPMANN, 2017)

Sharding

Sharding é uma forma de escalar o banco de dados relacional dividindo os dados, ao invés de tê-los em um único servidor, ou tê-los replicados em todos os servidores do cluster. É como se dividíssemos porções dos dados horizontalmente, hospedados separadamente em mais de um node.

É necessário pensar muito bem qual será a lógica para dividir os dados. De nada adianta, por exemplo, dividir dados de forma que as partes mais acessadas (hot spots) continuem juntas, já que não iremos "desafogar", escalar, o banco de fato.

Existem algumas estratégias bem conhecidas de sharding:

Por feature (segmentação funcional)
Por chave (key-based)

Recomendo fortemente a leitura do livro Designing Data Intensive Applications para navegar em assuntos complementares a esse texto:

Fontes:

CARPENTER, Jeff; HEWITT, Eben. Cassandra: The Difinitive Guide. O'Reilly, 2022.

KLEPPMANN, Martin. Designing Data-Intensive Applications. O'Reilly, 2017.

Concorrência e paralelismo em Python

Natália Oliveira — Thu, 02 Jan 2025 09:03:53 +0000

Texto originalmenete publicado aqui.

O objetivo deste texto é dar um resumo direto ao ponto dos conceitos básicos necessários para entender sobre concorrência a paralelismo na linguagem Python. Recomendo ter uma base mínima sobre o assunto ou aliar esse texto com estudo em outras fontes. Todas as referências estão ao final do texto.

Abordarei os seguintes tópicos:

O que é um processo?
O que são threads?
O que significa I/O bound e CPU bound?
O que é o GIL do Python?
O que é concorrência?
O que é paralelismo?
A biblioteca asyncio
A biblioteca threading
A biblioteca multiprocessing

O que é um processo?

Em computação um processo é uma instância de uma aplicação rodando. Se você abrir uma aplicação no seu computador, como o navegador, essa aplicação vai estar associada a algum processo. Um processo é composto por:

Contexto de hardware: armazena conteúdo de registradores gerais e específicos da CPU
Contexto de software: especifica os recursos que podem ser alocados pelo processo
Espaço de endereçamento: especifica a área da memória que o processo pertence

A imagem a seguir foi retirada do livro do Francis Machado e do Luis Maia:

Essas informações são necessárias para a execução de um programa.

O que são threads?

Uma thread é uma sub-rotina de um programa, sendo a menor unidade de execução que um sistema operacional gerencia e componente de um processo.

As várias threads de um processo hipotético podem ser executadas concorrentemente (que entenderemos em breve), compartilhando recursos como memória. Diferentes processos não compartilham esses recursos.

A imagem abaixo foi retirada do Wikipedia:

Interpretando a imagem acima, podemos extrair que um programa fica salvo em disco (memória secundária, não-volátil) e inclui várias instruções, podendo ser instanciado (iniciado) em um ou mais processos, e esses por sua vez podem ter várias threads associadas.

O que significa I/O bound e CPU bound?

Essas duas expressões aparecem bastante na discussão sobre concorrência e podem aparecer em português com E/S (entrada/saída) e UCP (unidade central de processamento).

Quando falamos sobre I/O bound e CPU bound estamos falando dos fatores limitantes que previnem uma operação de rodar mais rápido em nosso computador, e podemos encontrar esse dois tipos de operações na mesma codebase.

Uma operação CPU bound faz uso intenso da CPU, e rodará mais rápido se a CPU for mais poderosa. Ou seja, se formos de 2GHz para 4GHz de velocidade de clock essa operação provavelmente rodará mais rápido. Estamos falando aqui de operações que realizam muitas computações, cálculos; a exemplo, como calcular Pi.

Uma operação I/O bound depende da velocidade da rede e velocidade dos dispositivos de entrada e saída. Fazer um request a um servidor web ou ler um arquivo do disco são operações I/O bound.

Ambos os tipos de operações podem se beneficiar do uso de concorrência.

O que é o GIL do Python?

GIL significa global interpreter lock (bloqueio do interpretador global), cujo objetivo é prevenir um processo Python de executar mais de um bytecode de instrução Python ao mesmo tempo. Para rodar uma thread é necessário "adiquirir" o GIL e enquanto uma thread detém o GIL outra thread não pode adiquiri-lo ao mesmo tempo. Isso não significa que não podemos ter mais de uma thread nesse contexto.

Aqui estamos considerando a implementação de referência do Python. O CPython é a implementação padrão do Python, usada como referência de como a linguagem se comporta. Existem outras implementações, como Jython ou IronPython. O GIL está presente no CPython e só recentemente tivemos uma PEP (Python Enhancement Proposal - proposta de melhoria do Python) propondo tornar o GIL opcional.

A ideia do GIL é prevenir race conditions, que podem surgir quando mais de uma thread precisa referenciar um objeto Python ao mesmo tempo. Se mais de uma thread modificar uma variável compartilhada essa variável pode ficar em um estado inesperado. Imagem retirada do livro do Matthew Fowler:

Na imagem acima duas threads estão tentando incrementar uma reference count simultaneamente, e aí ao invés da contagem dar 2, já que as duas estão incrementando 1, o resultado final dá 1 (cada thread é uma coluna).

O que é concorrência?

Concorrência em computação acontece quando lida-se com mais de uma tarefas, sem necessariamente estar executando essas duas tarefas exatamente ao mesmo tempo. Uma frase conhecida do Rob Pyke sobre o assunto:

Concorrência significa lidar com muitas coisas ao mesmo tempo. Paralelismo é fazer muitas coisas ao mesmo tempo.

Pense nessa situação hipotética: se você for fazer dois bolos, pode começar pré-aquecendo o forno e, enquanto isso, prepara a massa do primeiro bolo. Assim que o forno estiver na temperatura correta você já pode colocar a massa do primeiro bolo no forno e, enquanto aguarda o bolo crescer no forno, já pode preparar a massa do segundo bolo. A ideia de concorrência é basicamente essa, você não precisa ficar ocioso, travado, parado, enquanto aguarda uma tarefa completar, você pode fazer um switch e trocar de tarefa.

Nesse contexto temos dois tipos de multitasking:

Cooperative multitasking: nesse modelo explicitamos no código os pontos onde se pode fazer o switch de tarefas. No Python isso é alcançado com o uso de um event loop, um design pattern comum, usando apenas uma thread e um core de CPU, usando, por exemplo, o asyncio com async e await
Preemptive multitasking: nesse modelo deixamos o sistema operacional lidar com o switch. No Python isso é alcançado com mais de uma thread e um core de CPU usando, por exemplo, a lib threading

A imagem abaixo ajuda a sumarizar concorrência em Python:

O que é paralelismo?

Paralelismo significa que mais de uma task está sendo executada ao mesmo tempo. Em outras palavras, paralelismo implica concorrência (lidar com mais de uma task), mas concorrência não implica paralelismo (tasks não estão necessariamente sendo executadas em paralelo, ao mesmo tempo). Para que paralelismo seja possível precisamos de mais de um core de CPU.

No Python paralelismo é alcançado, por exemplo, com a lib multiprocessing, onde teremos mais de um processo Python, cada um com seu GIL. A imagem ajuda a ilustrar paralelismo em Python:

A biblioteca asyncio

Existem formas diferentes de se atingir concorrência e paralelismo em Python e podemos utilizar algumas bibliotecas para otimizar nosso código, a depender do tipo de operação que estamos lidando, I/O bound ou CPU bound. O asyncio é uma lib para atingir concorrência usando o async e await. Pela documentação:

O asyncio é usado como uma base para várias estruturas assíncronas do Python que fornecem rede e servidores web de alto desempenho, bibliotecas de conexão de banco de dados, filas de tarefas distribuídas etc.

Como você pode imaginar, essa lib é adequada para otimizar tarefas I/O bound, onde temos tempo de espera de network, escrita em disco, etc. Numa operação CPU bound não há espera, dependemos apenas da velocidade de cálculo da CPU.

A biblioteca threading

A lib threading do Python nos permite operar mais de uma thread, porém, continuamos a lidar com um core de CPU e um processo Python, e lembre-se de que esse é um caso de preemptive multitasking onde o sistema operacional faz a troca de tarefas por nós. A lib também é mais útil para otimizar operações I/O bound.

Sobre o threading, o site Real Python traz alguns pontos importantes:

Porque o sistema operacional está no controle de quando uma task será interrompida e outra task irá começar, qualquer dado que for compartilhado entre as threads precisa ser protegido, ou thread-safe. Infelizmente requests.Session() não é thread-safe. Existem várias estratégias para fazer o acesso de dados thread-safe a depender de que dado é e como você está usando. Uma delas é usar estruturas de dados thread-safe como Queue do módulo queue do Python.

Encontramos a documentação do queue aqui.

A biblioteca multiprocessing

Sobre a lib multiprocessing na documentação do Python:

multiprocessing é um pacote que suporta gerar processos usando uma API similar ao módulo threading. O pacote multiprocessing oferece concorrência tanto local quanto remota, efetivamente desviando o GIL usando sub-processos ao invés de threads. Por isso o módulo multiprocessing permite o programador aproveitar múltiplos processadores em uma máquina.

Vale apontar que rodar mais de um processo em diferentes cores de CPU não significa desabilitar o GIL, e sim que cada processo terá o seu próprio GIL. Por aproveitar de mais de um core de CPU, compartilhando workloads pesados de CPU entre os múltiplos cores dispiníveis, a lib é mais adequada a CPU bound.

Fontes:

FOWLER, Matthew. Python Concurrency with asyncio. Manning Publications, 2022.

MACHADO, Francis Berenger; MAIA, Luiz Paulo. Arquitetura de Sistemas Operacionais: Incluindo Exercícios com o Simulador SOSIM e Questões do ENADE. Rio de Janeiro: LTC, 2013.

Thread (computing) por Wikipedia

Speed Up Your Python Program With Concurrency por Real Python

Como instalar o Terraform no Linux Mint

Natália Oliveira — Sun, 24 Mar 2024 22:44:25 +0000

Estou utilizando uma máquina virtual com o sistema operacional Linux Mint 21.2 Cinnamon e, ao tentar instalar o CLI do Terraform como manda a documentação, vi um erro de 404 Not Found (...) does not have a Release file:

$ sudo apt update
Err:11 https://apt.releases.hashicorp.com victoria Release
  404  Not Found [IP: 3.160.132.112 443]
Reading package lists... Done
E: The repository 'https://apt.releases.hashicorp.com victoria Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

O Mint não encontra o repósitorio apontado do Terraform e falha a atualização desse pacote. Encontrei essa issue do GitHub onde vemos o mesmo problema e, olhando a resposta, vemos que a HashiCorp só dá suporte a determinadas distro Linux e o Mint não é uma delas:

Tentando resolver esse problema cheguei num artigo do Medium do Tri Juhari. Basicamente, para resolver esse problema precisamos mudar o comando da documentação oficial:

$ echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

Para esse comando aqui:

$ echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(. /etc/os-release && echo "$UBUNTU_CODENAME") main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

O que mudou foi o comando $(lsb_release -cs) para $(. /etc/os-release && echo "$UBUNTU_CODENAME"). O primeiro vai retornar a versão da distro que estamos usando:

$ lsb_release -cs  
victoria

O Terraform não tem suporte para o release victoria. Se eu rodar o segundo comando terei a versão equivalente ao Ubuntu:

$ . /etc/os-release && echo "$UBUNTU_CODENAME"
jammy

Usando essa versão equivalente do Ubuntu conseguimos instalar o Terraform com sucesso:

O que são microservices (microsserviços)?

Natália Oliveira — Sat, 25 Nov 2023 20:07:32 +0000

Esse texto são anotações breves tiradas do vídeo sobre microsevices do canal TechWorld with Nana. As anotações são sobre os seguintes tópicos:

Arquitetura em monolito
O que são microsserviços
Microsserviços, CI/CD, polyrepo e monorepo

Arquitetura em monolito

Quando falamos em um monilito em tech estamos nos referindo a uma arquitetura onde o código inteiro de uma aplicação é uma unidade. Aqui, tudo é desenvolvido, deployado e escalado como uma unidade, e uma stack só.

Alguns desafios da arquitetura de monolito:

A aplicação se torna complexa demais para entender
As partes da aplicação se tornam muito entrelaçadas
Só dá para escalar a aplicação inteira, mesmo que só faça sentido escalar uma parte específica
Demora no release

Como possível solução desses desafios surgiu a arquitetura de microsserviços (em inglês, microservices).

O que são microsserviços?

Microsserviços são aplicações que seguem uma arquitetura onde uma aplicação é dividida entre serviços menores, independentes, que podem ter stacks diferentes, sendo desenvolvidos, deployados e escalados separadamente.

Para se comunicar entre si, é comum que microsserviços utilizem chamadas de APIs. Outra forma de comunicação é através de message brokers, como o RabbitMQ, onde temos filas no modelo publish/subscribe. Além disso, a comunicação pode ser feita também através de service mesh, que é um serviço que lida com toda a lógica de comunicação entre os microsserviços.

Alguns desafios de microsserviços:

Configurar a comunicação entre esses diversos serviços
Conseguir monitorar todos os múltiplos serviços entre servidores

Microsserviços, CI/CD, polyrepo e monorepo

Polyrepo é uma estratégia de gerência de código onde criamos vários repositórios, cada um com seu tracking de Git, por exemplo, e com isso acabamos por ter vários pipelines de CI/CD (continuous integration/continous deployment). É muito comum em empresas que seguem a arquitetura em microsserviços.

Por outro lado, a estratégia de monorepo nos faz lidar somente com um CI/CD pipeline, já que teremos várias pastas, com cada serviço, mas sendo trackeadas por um único controle de versão, por exemplo.

Fontes:
Microservices explained - the What, Why and How?, por TechWorld with Nana

Esse texto não tem intenção de esgotar o tema. Acrescente nos comentários, e também aponte erros quando os identificar.

Como deixar o Visual Studio Code minimalista

Natália Oliveira — Sat, 15 Jul 2023 09:18:45 +0000

Já sentiu seus olhos queimarem com algum esquema de cores no VScode? Enjoou do tema Dracula e está incomodado(a) com a quantidade de ícones que você não usa com frequência? Seus problemas acabaram!

Felizmente, podemos customizar muita coisa no VSCode. Fiz diversos ajustes no meu para ficar assim:

Quando instalamos o VSCode ele vem com uma barra lateral na esquerda, tabs the outline e timeline, uma tabulação bem apertada na estrutura de pastas do projeto, alguns ícones no canto superior direito, um mini mapa na direita e esse tema padrão:

É muita coisa. Vou mostrar aqui quais as extensões e configurações que uso para deixar a interface mais simples e fluida.

Tema minimalista: Plain theme

Alguns temas me lembram de como é usar marca-texto no texto inteiro. Procurei um tema mais simples e finalmente encontrei um: Plain theme. É um tema minimalista que destaca apenas algumas palavras e, que eu saiba, hoje em dia o VSCode por padrão já dá cor à parênteses/chaves/colchetes correspondentes.

Link para o Plain theme.

Como remover a barra lateral esquerda

Essa barra sempre me incomodou profundamente pois ocupa espaço na tela e nem sempre fico clicando ali. É onde fica o debug, source control, busca, etc. Hoje em dia acesso tudo com atalhos no teclado.

Para remover a barra lateral coloque isso no arquivo settings.json, que pode ser acessado com ctrl/cmd+shift+P e digitando "open user settings (JSON)":

"workbench.activityBar.visible": false

Como remover mini mapa

Para remover o mini mapa que fica na direita basta adicionar essa linha no settings.json:

"editor.minimap.enabled": false,

Como aumentar a tabulação do explorer

A tabulação padrão do VSCode é mínima e às vezes é difícil entender a hierarquia das pastas e arquivos. Para aumentar a tabulação adicione essa linha no settings.json:

"workbench.tree.indent": 20,

O número pode ser o que você achar mais conveniente.

Atalhos para abrir explorer, busca, debug e plugins

Removendo a barra lateral, precisei decorar os atalhos das funcionalidades que eu utilizo:

ctrl/cmd+shift+X: abre as extensões/plugins
ctrl/cmd+shift+B: abre/fecha a lateral inteira
ctrl/cmd+shift+F: abre a busca
ctrl/cmd+shift+D: abre o debug
ctrl/cmd+shift+E: abre a árvore de pastas e arquivos

Para saber todos os atalhos do VSCode você pode olhar esse documento em pdf para MacOS ou para Windows.

Como remover tabs da lateral esquerda

No meu caso não utilizo as tabs Outline ou Timeline. Para remover qualquer uma das tabs basta clicar com o botão direito do mouse em cima do nome da tab e clicar na opção que você quer habilitar/desabilitar:

Como remover ícones

Todos os ícones podem ser habilitados/desabilitados da interface. Clique em cima deles com o click direito do mouse e veja as opções:

Se quiser saber como está o meu settings.json dê uma olhada nesse link do Gist.

Esse texto não tem intenção de esgotar o tema. Acrescente nos comentários, e também aponte erros quando os identificar.

Kubernetes: resumo de conceitos básicos

Natália Oliveira — Mon, 05 Jun 2023 14:04:36 +0000

Se você está procurando um conteúdo enxuto e direto ao ponto sobre o básico de Kubernetes, este é o lugar. Todos os conceitos apresentados aqui foram tirados diretamente da documentação do Kubernetes. Irei responder as seguintes perguntas:

O que é Kubernetes?
Para que serve o Kubernetes?
Quais os componentes básicos do Kubernetes?
O que é um cluster?
O que são nodes?
O que são pods?
O que é o control plane?
O que é kubectl?

O que é Kubernetes?

O Kubernetes é uma plataforma open source portável, extensível, para gerenciar workloads e serviços containerizados, que facilita configuração declarativa e automação. Um workload é uma aplicação rodando no Kubernetes, e um serviço containerizado é quando usamos, por exemplo, o Docker para criar containers.

Para que serve o Kubernetes?

Além de gerenciar workloads e serviços containerizados, o Kubernetes provê:

Service discovery e load balancing: ele expõe um container usando o nome DNS ou IP e, se o tráfego estiver alto, ele pode balancear e distribuir pela network. Service discovery é o processo de detectar automaticamente devices e serviços numa rede de computadores
Orquestração de armazenamento: ele te permite montar um sistema de armazenamento a sua escolha, como local storage e cloud providers públicos
Rollouts e rollbacks automáticos: você pode descrever o estado desejado para o container deployado e o Kubernetes consegue controlar o estado de acordo com o que você descreveu
Bin packing automático: você diz o quanto de CPU e RAM cada container precisa e o Kubernetes lida com os recursos descritos da melhor forma
Self-healing: o Kubernetes reinicia containers que falharam, substitui containers, mata containers que não respondem ao health-check definido e não expõe o container para clientes até que eles estejam prontos
Gerenciamento de configuração e secrets: ele também te deixa guardar e gerenciar informações sensíveis como senhas, OAuth tokens, SSH keys, etc

Quais os componentes básicos do Kubernetes?

Os componentes básicos do Kubernetes são:

Cluster
Node
Pod
Control plane
Complementos: DNS, dashboard do Kubernetes, cluster-level logging, entre outros

Quando fazemos deploy do Kubernetes nós temos um cluster. Para ter um cluster Kubernetes funcionando precisamos desses componentes:

O que é um cluster?

Um cluster é um conjunto de worker machines, que são chamadas de nodes. Cada cluster tem pelo menos um worker node.

O que são nodes?

Nodes rodam aplicações containerizadas no Kubernetes, e as worker nodes são hosts para pods. Os nodes têm os seguintes componentes:

kubelet: um agente que roda em cada node do cluster, verificando se containers estão rodando num pod
kube-proxy: é uma network proxy, ou seja, uma aplicação que atua como intermediário entre um cliente e um servidor, que roda em cada node do cluster, implementando uma parte do conceito de service do Kubernetes. O kube-proxy mantém regras de network nos nodes, e essas regras permitem comunicações de rede para seus pods de sessions dentro ou fora do cluster
Container runtime: é o software que é responsável por rodar os containers, como o containerd e o CRI-O

O que são pods?

Um pod é um conjunto de containers rodando no cluster Kubernetes.

O que é o control plane?

O control plane gerencia os worker nodes e os pods no cluster. Em ambientes de produção ele geralmente roda em vários computadores e um cluster geralmente roda vários nodes. Os componentes do control plane tomam decisões globais sobre o cluster, detectando e respondendo a eventos do cluster como, por exemplo, startar um pod.

O control plane é composto de:

kube-apiserver: expõe a API do Kubernetes, como se fosse o frontend para o Kubernetes control plane
etcd: armazenamento de chave/valor para todos os dados do cluster
kube-scheduler: é o componente que verifica novos pods criados que estão sem node definido, selecionando um node onde eles possam rodar
kube-controller-manager: componente que roda processos do controller. Cada controller, como o node controller, job controller e o ServiceAccount controller, é um processo separado, entretanto, são todos compilados em um único binário e rodados como um único processo
cloud-controller-manager: componente que tem lógica de controle específica do provedor de cloud, permitindo que você link seu cluster com a API do provedor

O que é kubectl?

É a ferramenta de linha de comando do Kubernetes para se comunicar com o control plane do cluster, usando a API do Kubernetes. Sintaxe do kubectl:

kubectl [command] [TYPE] [NAME] [flags]

Exemplo de comando para listar todos os pods dentro de um namespace (um namespace é uma forma de isolar um grupo de recursos):

kubectl get pods

Fontes:
Documentação do Kubernetes
Service discovery na Wikipedia
Proxy server na Wikipedia

Esse texto não tem intenção de esgotar o tema. Acrescente nos comentários, e também aponte erros quando os identificar.

Como criar um container com MySQL Server com Docker e conectá-lo no Workbench [Linux]

Natália Oliveira — Wed, 26 Jan 2022 11:06:40 +0000

Esse texto tem fins educacionais. Fiz o procedimento para acompanhar a matéria de banco de dados na faculdade e espero que te ajude a estudar algumas coisinhas.

Caso não tenha o Docker instalado ainda, abra o terminal e atualize os pacotes:

sudo apt-get update

Instale esses pacotes:

sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

Adicione a GPG key oficial do Docker:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Adicione o repositório:

sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

Atualize os pacotes novamente e adicione o Docker Engine:

sudo apt-get install docker-ce docker-ce-cli containerd.io

Para evitar ter que usar o sudo o tempo todo, crie um grupo docker e adicione seu user no grupo:

$ sudo groupadd docker
$ sudo usermod -aG docker $USER
$ newgrp docker

Abra e feche o terminal, depois rode um docker run hello-world para checar que está tudo ok.

Criando container com MySQL Server

Para criar um container com o MySQL faça o seguinte:

docker run -p 3306:3306 --name=seu-container -d mysql/mysql-server

Esse comando roda um container chamado “seu-container” a partir de uma imagem do MySQL Server e mapeia a porta 3306 do container com a sua de mesmo número. Dê um docker ps e veja o que tem rodando na sua máquina.

Se conectando no MySQL Server e configurando senha

Pegue a senha randômica gerada:

docker logs seu-container 2>&1 | grep GENERATED

Copie a root password que apareceu e rode o comando:

docker exec -it seu-container mysql -uroot -p

Cole a password e dê enter. Depois disso, já no server, digite:

ALTER USER 'root'@'localhost' IDENTIFIED BY '12345';

Isso vai mudar a senha padrão do usuário para 12345. Depois rode o seguinte:

update mysql.user set host = '%' where user='root';

Esse comando vai permitir que você conecte o Workbench no container. Dê um ctrl-D e depois um docker restart seu-container.

Conectando no MySQL Workbench

Vá ao MySQL Workbench e clique na instância local:

Depois disso você poderá colocar a senha:

Pronto, aparecerá uma telinha e aconselho você a explorar o que tem nela.

Fontes:
MySQL Server Docker
StackOverflow
Install Docker

Esse texto não tem intenção de esgotar o tema. Acrescente nos comentários, e também aponte erros quando os identificar.

Comandos básicos do Vim e configurações úteis

Natália Oliveira — Wed, 19 Jan 2022 10:13:01 +0000

Hoje vou falar um pouco sobre esse editor de texto chamado Vim. Se você já se pegou perguntando como entrar no vim, como sair do vim, como editar no vim, como adicionar plugins no vim ou coisas do tipo, esse texto é para você.

A intenção aqui é ser “pá-pum”, bem direto ao ponto, um resuminho para quem nunca usou esse editor de texto hardcore. Me lembro de ter visto alguns handbooks na época em que comecei, mas o que proponho aqui é bem mais enxuto.

Como instalar o Vim

A instalação básica que costumo fazer é essa:

$ sudo apt install vim

Se você for no site oficial do editor de texto verá que há outra forma de instalar, mas por praticidade pode seguir com a acima.

Como configurar o Vim

O Vim instalado por si só não tem configurações úteis que nos fariam pensar, por exemplo, em abandonar o VS Code (eu acho rs). Para isso configuramos algumas coisas criando um arquivo chamado .vimrc para deixá-lo mais esperto.

Dentro do meu .vimrc eu tenho algumas configurações, por exemplo:

set number
set linebreak
set showbreak=+++
set textwidth=100
set autoindent
set shiftwidth=2
set smartindent
set smarttab
set softtabstop=2
set undolevels=1000
set background=dark
set backspace=indent,eol,start

Cada uma dessas configurações tem uma utilidade e te encorajo a pesquisar sobre cada uma delas. O set number, por exemplo, faz com que seja mostrada a numeração de cada linha no editor, o que é muito útil.

Coloquei meu .vimrc completo esse repositório no GitHub, caso tenha curiosidade.

Gerenciando plugins

Para o Vim ficar ainda mais interessante, muitas pessoas utilizam um gerenciador de plugins para instalar plugins variados. Atualmente utilizo o Vundle Vim.

Para instalar o Vundle, digite no seu terminal:

$ git clone https://github.com/VundleVim/Vundle.vim.git ~/.vim/bundle/Vundle.vim

É necessário que o seu .vimrc tenha algumas informações para funcionar com o Vundle corretamente:

set nocompatible              " be iMproved, required
filetype off                  " required

" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" alternatively, pass a path where Vundle should install plugins
"call vundle#begin('~/some/path/here')

" let Vundle manage Vundle, required
Plugin 'VundleVim/Vundle.vim'

" The following are examples of different formats supported.
" Keep Plugin commands between vundle#begin/end.
" plugin on GitHub repo
Plugin 'tpope/vim-fugitive'
" plugin from http://vim-scripts.org/vim/scripts.html
" Plugin 'L9'
" Git plugin not hosted on GitHub
Plugin 'git://git.wincent.com/command-t.git'
" git repos on your local machine (i.e. when working on your own plugin)
Plugin 'file:///home/gmarik/path/to/plugin'
" The sparkup vim script is in a subdirectory of this repo called vim.
" Pass the path to set the runtimepath properly.
Plugin 'rstacruz/sparkup', {'rtp': 'vim/'}
" Install L9 and avoid a Naming conflict if you've already installed a
" different version somewhere else.
" Plugin 'ascenator/L9', {'name': 'newL9'}

" All of your Plugins must be added before the following line
call vundle#end()            " required
filetype plugin indent on    " required
" To ignore plugin indent changes, instead use:
"filetype plugin on
"
" Brief help
" :PluginList       - lists configured plugins
" :PluginInstall    - installs plugins; append `!` to update or just :PluginUpdate
" :PluginSearch foo - searches for foo; append `!` to refresh local cache
" :PluginClean      - confirms removal of unused plugins; append `!` to auto-approve removal
"
" see :h vundle for more details or wiki for FAQ
" Put your non-Plugin stuff after this line

O texto acima foi retirado diretamente da documentação e explica, em comentários (toda linha com aspas duplas é um comentário), algumas opções de como usar o Vundle e onde colocar cada informação no seu .vimrc.

Na última linha do arquivo temos algo como coloque todas as informações que não são de plugins depois dessa linha: é no final do arquivo que ficam nossas configurações básicas do Vim que falamos anteriormente.

Localize as linhas que não estão com aspas duplas que começam com “Plugin”. Pronto, esses são alguns plugins que eles colocam de exemplo nesse arquivo para ilustrar.

Vamos configurar um .vimrc com Vundle agora. No seu terminal, digite:

$ vim .vimrc

Isso vai abrir o Vim com o arquivo .vimrc. Já no editor, dê um ctrl i e cole com ctrl shift v (deixei uns comentários para que você possa entender melhor):

" configurações essenciais
set nocompatible              " be iMproved, required
filetype off                  " required
set rtp+=~/.vim/bundle/Vundle.vim
" início da chamada de plugins
call vundle#begin()

Plugin 'VundleVim/Vundle.vim'
Plugin 'scrooloose/nerdtree'
Plugin 'majutsushi/tagbar'
Plugin 'tpope/vim-surround'
Plugin 'scrooloose/syntastic'
Plugin 'jiangmiao/auto-pairs'
Plugin 'morhetz/gruvbox'
Plugin 'valloric/youcompleteme' 

" fim da chamada de plugins
call vundle#end()            " required
filetype plugin indent on    " required

" configurações básicas do Vim
set number
set linebreak
set showbreak=+++
set textwidth=100
set showmatch
set hlsearch
set smartcase
set ignorecase
set incsearch
set autoindent
set shiftwidth=2
set smartindent
set smarttab
set softtabstop=2
set undolevels=1000
set background=dark
set backspace=indent,eol,start
colorscheme gruvbox

Para definir meus plugins fui analisando a necessidade e procurando num site chamado Vim Awesome.

Essa é a cara do meu Vim atual quando abro algum arquivo:

A árvore de arquivos e pastas é proporcionada pelo Plugin 'scrooloose/nerdtree'
O tema (colorscheme) é o Plugin 'morhetz/gruvbox'
A linha com informações no canto inferior da tela vem do Plugin 'majutsushi/tagbar'

Editando códigos e usando os plugins

No início anotei comandos no papel e fui olhando sempre até decorar. Hoje em dia utilizo um plugin no VS Code que me permite utilizar comandos do Vim, porque acabei me acostumando com a praticidade.

Mas como gosto de utilizar também alguns comandos do VS Code, precisei adequar algumas coisas nas minhas configurações. Aqui estão as minhas settings do VS Code, caso tenha interesse. Tudo que tem vim.handleKeys é para que eu possa utilizar “ctrl-alguma tecla” do VS Code ao invés do Vim.

Modos do Vim

O Vim tem alguns modos:

Normal mode: para se movimentar pelo texto
Insert mode: para escrever no texto
Visual mode: para selecionar parte do texto
Command mode: para dar algum comando ao Vim

Comandos básicos no modo normal

esc: sair do modo atual e ir para o modo de comando
j: mover o cursor para baixo
k: mover o cursor para cima
h: mover o cursor para a esquerda
l: mover o cursor para a direita
ctrl i: entrar no modo de edição no caracter em que está
esc: sair do modo atual e ir para os comandos
shift a: entrar no modo de edição no final da linha
shift o: entra no modo de edição em uma nova linha abaixo da atual
gg: ir para o início do arquivo
shift g: ir para o final do arquivo
w: pular uma palavra para frente
b: pular uma palavra para trás
ctrl ]: pular um bloco de código para baixo
ctrl [: pular um bloco de código para cima
y: copiar código
c: recortar código
p: colar código um caractere depois do atual
x: deletar caractere
dd: deletar linha
ctrl u: desfazer
ctrl r: refazer
shift o: abre uma nova linha de edição empurrando para baixo o código da linha

Comandos no modo de comando

Entramos nesse modo depois de dar um esc. Perceba que aqui nós precisamos digitar dois pontos para dar o comando e dar enter no final. Aqui os comandos aparecem sendo digitados no canto inferior da tela (lá no finzinho).

:q: sair do arquivo atual
:q!: saída forçada do arquivo atual
:w: salvar
:wq: salvar e sair

Comandos no modo visual

Com o v entramos no visual mode, e com os comandos do modo normal movemos o cursor para que selecione o texto que queremos. Ficará um VISUAL no canto inferior.

x: deleta o que está selecionado
y: copia o que está selecionado
s: entra no modo de edição substituindo o que tinha antes
c: recorta o código selecionado

Para copiar o código selecionado em algum lugar, dê um esc para voltar ao modo normal e depois um p (paste) no local desejado.

Comandos do Vundle e do plugin NERDTree

Para instalar os plugins que você definiu no seu .vimrc entre no Vim e, no modo de comando, digite:

:PluginInstall

Vai aparecer uma telinha como essa:

É só dar esc, depois :q e enter para sair. Para desinstalar um plugin delete a linha no .vimrc e depois faça o mesmo esquema só que com :PluginClean.

Para acessar a árvore de comandos que eu instalei, vá para o modo de comando e digite:

:NERDTree

Você pode navegar na NERDTree como no normal mode. Para abrir uma pasta pressione o, para fechá-la, pressione novamente.

Para abrir um arquivo do lado pressione o no arquivo. Para abrir outro arquivo na vertical, dividindo a tela com um arquivo já aberto, pressione i.

Para rodar entre os arquivos abertos e a árvore de arquivos pressione ctrl w e mais uma das teclas principais de navegação (h, j, k, l).

Cada plugin tem uma documentação e você deve ler cada uma delas para entender o que fazer. Não tem para onde correr!

Para usar o Vim como editor principal é necessário aprender vários comandos e configurar muita coisa, então veja bem se você tem interesse de desprender esse tempo aprendendo. O importante mesmo é saber usar bem a ferramenta que você escolheu.

Esse texto não tem intenção de esgotar o tema. Acrescente nos comentários, e também aponte erros quando os identificar.