DEV Community: Cadu Magalhães

Roadmap de Engenharia de Dados para 2025

Cadu Magalhães — Fri, 25 Jul 2025 19:56:27 +0000

Tenho 2 objetivos com esse roadmap: primeiro, é uma lista muito completa dos assuntos que acredito que te fariam ser fora da curva na área de Engenharia de Dados. Segundo, é a lista dos assuntos que pretendo cumprir no blog.

Em alguns tópicos já deixei quais serão os posts, mas isso pode mudar. A ordem também não é certa, visto que muito do que está aqui não é sequencial.

Já tenho material revisado para um mês de publicação, começando com o post de História e evolução da Engenharia de Dados, para o dia 01 de Agosto de 2025. Sinto que em tempos de conteúdo e código escritos por IA, minha forma de resistir é fazer essas publicações. Tentar construir conteúdo de qualidade, com muita curadoria e pesquisa, e que traz o que eu pessoalmente acho interessante -contexto, história - para contribuir com a parte técnica.

Introdução e Contexto Histórico
Nível 101 – Iniciante
- 1. Fundamentos de Bancos de Dados
  - 1.1 Conceitos Teóricos
  - 1.2 Exemplos Práticos
- 2. Pipelines de Dados
  - 2.1 Conceitos Teóricos
  - 2.2 Exemplos Práticos
- 3. Fundamentos de Arquitetura de Dados
  - 3.1 Conceitos Teóricos
  - 3.2 Exemplos Práticos
- 4. Desenvolvimento e Ferramentas Essenciais
  - 4.1 Linguagem de Programação
  - 4.2 SQL
  - 4.3 APIs
Nível 201 – Intermediário / Preparando-se para o Mercado
- 1. Arquitetura de Dados Avançada
  - 1.1 Conceitos Teóricos
  - 1.2 Exemplos Práticos
- 2. Modelagem de Dados
  - 2.1 Conceitos Teóricos
  - 2.2 Exemplos Práticos
- 3. Transformação de Dados e Apache Spark
  - 3.1 Conceitos Teóricos
  - 3.2 Exemplos Práticos
- 4. SQL Avançado
  - 4.1 Conceitos Teóricos
- 5. Fundamentos de Cloud Computing e DataOps
  - 5.1 Cloud Computing
  - 5.2 DataOps
- 6. Orquestradores de Dados
  - 6.1 Conceitos Teóricos
- 7. No Code e Low Code em Engenharia de Dados
  - 7.1 Conceitos Teóricos
- 8. Soft Skills e Gestão de Projetos
  - 8.1 Conceitos Teóricos
- 9. Conceitos Avançados em Analytics Engineering
  - 9.1 Conceitos Teóricos
Nível 301 – Avançado e Tendências
- 1. Processamento de Dados em Streaming e Arquiteturas em Tempo Real
  - 1.1 Conceitos Teóricos
  - 1.2 Exemplos Práticos
- 2. Observabilidade, Monitoramento e Documentação de Dados
  - 2.1 Conceitos Teóricos
  - 2.2 Exemplos Práticos
- 3. Data Quality e Governança
  - 3.1 Conceitos Teóricos
  - 3.2 Exemplos Práticos
- 4. Engenharia de Software Aplicada à Engenharia de Dados
  - 4.1 Conceitos Teóricos
  - 4.2 Exemplos Práticos
- 5. Mensageria e Integração em Tempo Real
  - 5.1 Conceitos Teóricos
  - 5.2 Exemplos Práticos
- 6. MLOps
  - 6.1 Conceitos Teóricos
  - 6.2 Exemplos Práticos
Módulo de Carreira e Desenvolvimento Profissional
- 1. Certificações
- 2. Preparação para Entrevistas
Sugestões de Livros e Referências Essenciais
Conclusões

Introdução e Contexto Histórico

Evolução dos bancos de dados: do modelo relacional, ACID, às origens dos bancos NoSQL.
Surgimento do Big Data: Hadoop, MapReduce e a evolução para frameworks distribuídos como Spark e Flink.
Transição do armazenamento on-premise para a era da nuvem.
Impactos da Engenharia de Software

Posts Relacionados:

Introdução à Engenharia de Dados
História e evolução da Engenharia de Dados

Nível 101 – Iniciante

1. Fundamentos de Bancos de Dados

1.1 Conceitos Teóricos

Modelos de Bancos de Dados:
- Relacional: Estrutura tabular, integridade referencial.
- Não Relacional: Documentos, key-value, grafos, colunar, in-memory, timeseries.
- OLTP: Foco em operações transacionais com alta frequência.
- OLAP: Ambientes otimizados para análises multi dimensionais e consultas complexas.
Transações:
- Conceitos de atomicidade, consistência, isolamento e durabilidade (ACID).
- Exemplos práticos de rollback, commit e gerenciamento de concorrência.
Casos de Uso e Quando Utilizar Cada Tipo:
- Bancos relacionais para transações críticas e integridade dos dados.
- Bancos não relacionais para escalabilidade, flexibilidade de esquemas e alta performance.

1.2 Exemplos Práticos

Bancos Relacionais:
- Criação de esquemas, tabelas, índices e realização de transações (ex.: PostgreSQL).
Bancos NoSQL:
- Implementação de operações CRUD em MongoDB ou Redis, com exemplos de indexação e consultas.

Posts Relacionados:

Engenharia de dados 101 – Fundamentos de bancos de dados

2. Pipelines de Dados

2.1 Conceitos Teóricos

ETL:
- Extração, transformação e carregamento: processos, vantagens e desafios.
ELT:
- Extração, carregamento e, posteriormente, transformação: quando utilizar e vantagens.
Comparação ETL x ELT:
- Critérios para escolha, impacto em performance, custo e arquitetura.
Processamento de Dados:
- Batch: Processamento em blocos com execução agendada.
- Streaming: Processamento em tempo real, com tolerância à latência.
- Arquiteturas Híbridas: Combinação de batch e streaming para cenários específicos.
Introdução a modelagem de dados:
- Incremental Load: Carregamento de dados apenas quando há mudanças.
- Row Versioning: Manutenção de versões das linhas para auditoria e concorrência.

2.2 Exemplos Práticos

Implementação de ETL:
- Script em Python para extrair, transformar e carregar dados.
Implementação de ELT:
- Carregamento de dados brutos em um data warehouse e transformações via SQL.
Processamento Batch x Streaming:
- Demonstração com Apache Spark (modos batch e streaming) e exemplos de arquiteturas híbridas.

Posts Relacionados:

Engenharia de dados 101 – Fundamentos de Pipelines de dados

3. Fundamentos de Arquitetura de Dados

3.1 Conceitos Teóricos

Data Warehouse:
- Conceitos, arquitetura e casos de uso.
Data Lake:
- Armazenamento de dados brutos, escalabilidade e flexibilidade.
Data Mart:
- Subconjuntos de dados específicos para áreas de negócio.
Arquiteturas Híbridas:
- Integração de múltiplos conceitos para atender cenários complexos.

3.2 Exemplos Práticos

Implementação de um Data Warehouse:
- Projeto básico utilizando ferramentas open-source.
Construção de um Data Lake:
- Demonstração de ingestão e organização de dados brutos. Posts Relacionados:
Engenharia de dados 101 – Fundamentos de arquitetura de dados

4. Desenvolvimento e Ferramentas Essenciais

4.1 Linguagem de Programação

Tipos de Dados e Estruturas Básicas:
- Tipos de Dados: Trabalhar com strings, números, booleanos, etc.
- Estruturas Básicas: Listas, tuplas, dicionários e conjuntos.
Programação Orientada a Objetos:
- Conceitos de classes e objetos.
- Implementação de métodos padrão (ex.: __add__, __get__, etc).
Estruturas de Dados Avançadas:
- Árvores, grafos, heaps, e outros conceitos fundamentais da ciência da computação que auxiliam na criação de algoritmos eficientes.
Gerenciamento de Pacotes e Organização de Projetos:
- Ferramentas para gerenciamento de pacotes: pip, Poetry, uv, etc.
- Construção e disponibilização de bibliotecas, organização de projetos e uso de ambientes virtuais.
Manipulação de Arquivos:
- Leitura e escrita em diferentes formatos: CSV, JSON, YAML, TOML.
Testes e Qualidade de Código:
- Boas práticas de testes unitários e integração para garantir a robustez do código.
Conceitos e Técnicas Modernas:
- Uso de context managers, dataclasses e decorators.
- Programação assíncrona com async/await.

4.2 SQL

Definição e Manipulação de Dados (DDL & DML):
- Comandos básicos: CREATE, REPLACE, UPDATE, INSERT, DELETE.
Consulta de Dados (DQL):
- Utilização de operadores condicionais e lógicos.
- Ordenação, definição de limites (LIMIT, OFFSET) e união de resultados.
- Junções (JOINs) para combinar dados de múltiplas tabelas.
- Funções de agregação, como COUNT, SUM, AVG, entre outras.
- Tratamento de texto com funções como LOWER, UPPER, CONCAT e expressões regulares.
- Funções de manipulação de datas e timestamps.
- Uso de subconsultas e Common Table Expressions (CTEs).

4.3 APIs

Conceitos Fundamentais:
- Princípios de APIs REST: métodos HTTP (GET, POST, PUT, DELETE), códigos de status e autenticação.
Boas Práticas e Estratégias:
- Implementação de estratégias de tratamento de falhas e retry.
- Gerenciamento de requisições paginadas.
Desenvolvimento de APIs:
- Princípios e práticas para a construção de uma API própria, desde o design até a implementação.

Posts Relacionados:

Engenharia de dados 101 – Fundamentos de Python
Python aplicado à Engenharia de Dados
Engenharia de dados 101 – Fundamentos de SQL
Engenharia de dados 101 – Criando e consumindo API’s

Essa estrutura detalhada garante que cada aspecto essencial da programação, SQL e APIs seja abordado de forma clara e completa, facilitando a compreensão e aplicação dos conceitos na prática.

Nível 201 – Intermediário / Preparando-se para o Mercado

1. Arquitetura de Dados Avançada

1.1 Conceitos Teóricos

Listagem e Definição de Arquiteturas:
- Revisão avançada de Data Warehouse, Data Lake e Data Mart.
- Data Mesh e Data Lakehouse: Conceitos emergentes e seus impactos.
Arquiteturas Lambda, Kappa e Medallion:
- Princípios, benefícios, desafios e comparação teórica.
Tópico de Comparação Teórica:
- Critérios, casos de uso e trade-offs entre as arquiteturas.

1.2 Exemplos Práticos

Implementação Prática:
- Projetos demonstrando uma arquitetura Medallion com ferramentas de transformação e ingestão de dados.
- Orquestração de pipelines em arquiteturas Lambda ou Kappa.

Posts Relacionados:

Engenharia de dados 201 – Arquitetura de dados

2. Modelagem de Dados

2.1 Conceitos Teóricos

Conceitos Fundamentais:
- Indexação: Técnicas para acelerar consultas.
- Normalização e Desnormalização: Teoria, vantagens e desvantagens.
- Slowly Changing Dimensions (SCD): Gerenciamento de alterações em dados dimensionais.
- Change Data Capture (CDC): Captura das alterações ocorridas em sistemas operacionais.
Formatos de Modelagem:
- Modelagem Relacional: Estrutura e integridade.
- Modelagem Dimensional: (Star schema, Snowflake) para BI e análises.
- One Big Table: Quando e como utilizar.
- Outras Abordagens: Data Vault, modelagem em grafos, etc.

2.2 Exemplos Práticos

Exercícios Práticos:
- Criação de modelos de dados para cenários variados.
- Otimização de consultas e demonstrações de normalização/desnormalização.

Posts Relacionados:

Engenharia de dados 201 – Modelagem de dados

3. Transformação de Dados e Apache Spark

3.1 Conceitos Teóricos

Frameworks de Transformação:
- Foco em Apache Spark: Conceitos de RDD, DataFrame, Spark SQL e streaming com Spark.
- Menção breve a outros frameworks (Apache Beam, Hadoop) e comparação conceitual.
dbt e Outras Ferramentas:
- Teoria sobre dbt (Data Build Tool) e outras alternativas para transformação de dados.

3.2 Exemplos Práticos

Projeto Spark:
- Post exclusivo ensinando a configurar, desenvolver e executar um job de transformação com Spark – do consumo à escrita em um data warehouse.
Implementação com dbt:
- Exemplo prático de transformação utilizando dbt.

Posts Relacionados:

Engenharia de dados 201 – Frameworks de transformação de dados
Engenharia de dados 201 – Fundamentos de PySpark

4. SQL Avançado

4.1 Conceitos Teóricos

Tópicos Avançados:
- Funções de janela, técnicas de otimização, análise de planos de execução e tuning de performance.
Casos de Uso:
- Exemplos de como extrair insights complexos de grandes volumes de dados usando SQL avançado.
Desafios SQL:
- Exercícios práticos para resolver problemas de performance e implementar consultas complexas.

Posts Relacionados:

Engenharia de dados 201 – SQL Avançado
Engenharia de dados 201 - Otimização de consultas SQL

5. Fundamentos de Cloud Computing e DataOps

5.1 Cloud Computing

Conceitos de Infraestrutura:
- Noções de redes, infraestrutura, sistemas operacionais, firewall, dns, e comparação entre soluções cloud (AWS, Azure, GCP) e ambientes on-premise.
- Serverless x Gerenciado
Serverless e Cloud Native:
- Containers, Kubernetes e CNCF
- Abordagem de funções serverless e arquiteturas orientadas a eventos.

5.2 DataOps

Integração de Práticas DevOps em Dados:
- Testes de código e de dados, versionamento e orquestração contínua (CI/CD).
Alertas, Monitoramento e Alta Disponibilidade:
- Estratégias para configurar alertas, dashboards, logs e tracing (usando Open Metrics, Open Telemetry) para garantir resiliência e disponibilidade.

Posts Relacionados:

Engenharia de dados 201 – Fundamentos de Cloud Computing
Engenharia de dados 201 – Fundamentos de DataOps

6. Orquestradores de Dados

talvez mencionar aqui em orquestração sobre ferramentas de extração (airbyte, fivetran, etc)

6.1 Conceitos Teóricos

Comparativo de Soluções:
- Análise das principais ferramentas: Airflow, Dagster, Prefect, Mage
- Introdução a orquestradores mais gerais, como o n8n.
- Ferramentas dentro de provedores (gcp workflows, azure data factory, aws step functions, databricks jobs, snowflake data pipelines, etc)
Apache Airflow:
- Funcionamento, principais conceitos (DAGs, Operators, Hooks) e casos de uso.
- Criação de pipelines com Airflow, integração com APIs e bancos de dados.
- Airflow moderno: taskflow api, agendamento por datasets, agendamentos complexos com timetables

Posts Relacionados:

Engenharia de dados 201 – Orquestradores de Dados
Engenharia de dados 201 – Fundamentos de Apache Airflow
Tudo que você precisa saber sobre Apache Airflow

7. No Code e Low Code em Engenharia de Dados

7.1 Conceitos Teóricos

Ferramentas No Code/Low Code:
- Introdução ao Apache Hop e outras plataformas como KNIME, Alteryx, Google DataPrep, Talend Data Preparation.
Vantagens e Desafios:
- Quando e por que utilizar abordagens no code/low code na engenharia de dados.
Demonstração de um Projeto No Code:
- Configuração e execução de um pipeline utilizando uma dessas ferramentas, enfatizando facilidade de integração e visualização.

Posts Relacionados:

Engenharia de dados 201 – No Code/Low Code em Engenharia de Dados

8. Soft Skills e Gestão de Projetos

8.1 Conceitos Teóricos

Comunicação e Documentação:
- Técnicas de storytelling com dados, documentação eficaz e visualização para stakeholders.
Gestão Ágil de Projetos:
- Metodologias ágeis e frameworks de gerenciamento aplicados a projetos de dados.
Colaboração e Liderança:
- Desenvolvimento de habilidades interpessoais e liderança em equipes multidisciplinares.

Posts Relacionados:

Engenharia de dados 201 – Soft Skills e Gestão de Projetos

9. Conceitos Avançados em Analytics Engineering

9.1 Conceitos Teóricos

Transformação para Analytics:
- Uso de ferramentas como dbt para criar modelos analíticos robustos, camadas semânticas e data marts focados em BI.
Integração com BI e Data Visualization:
- Estratégias para conectar pipelines a ferramentas de visualização (Looker, Tableau, Power BI) e modelagem de dados para análises avançadas.
Projeto de Analytics Engineering:
- Criação de um pipeline completo que vai da ingestão de dados à construção de dashboards interativos e insights de negócios.

Posts Relacionados:

Engenharia de dados 201 – Fundamentos de Analytics Engineering

Nível 301 – Avançado e Tendências

1. Processamento de Dados em Streaming e Arquiteturas em Tempo Real

1.1 Conceitos Teóricos

Processamento Streaming:
- Comparativo entre Spark Streaming, Apache Flink, Kafka Streams e outros.
Arquiteturas em Tempo Real:
- Processamento de eventos e aplicações críticas em tempo real.

1.2 Exemplos Práticos

Pipeline de Streaming:
- Desenvolvimento de um pipeline integrado com Kafka ou ferramentas similares.

Posts Relacionados:

Engenharia de dados 301 – Processamento de dados em streaming

2. Observabilidade, Monitoramento e Documentação de Dados

2.1 Conceitos Teóricos

Observabilidade e Monitoramento:
- Estratégias de logging, métricas, tracing e alertas usando ferramentas como Grafana e Kibana.
Documentação de Dados e Governança:
- Boas práticas para rastreamento de lineage, catalogação (Data Catalogs) e manutenção da documentação contínua.

2.2 Exemplos Práticos

Dashboards e Automação:
- Configuração de dashboards e criação de processos automatizados de documentação.

Posts Relacionados:

Engenharia de dados 301 – Observabilidade
(Novo) Engenharia de dados 301 – Documentação e Governança de Dados

3. Data Quality e Governança

3.1 Conceitos Teóricos

Qualidade dos Dados:
- Testes unitários e de dados, validação, auditoria e políticas de compliance (LGPD, GDPR).
Criptografia, mascaramento, controle de acesso, compliance e Data Anonymization (técnicas de anonimização para proteger dados sensíveis).

3.2 Exemplos Práticos

Processos Automatizados:
- Implementação de pipelines de validação e monitoramento da qualidade dos dados.

Posts Relacionados:

Engenharia de dados 301 – Data Quality

4. Engenharia de Software Aplicada à Engenharia de Dados

4.1 Conceitos Teóricos

Sistemas Distribuídos e Concorrência:
- Fundamentos, desafios e padrões de design para sistemas escaláveis.
Integração com Microserviços:
- Arquiteturas orientadas a eventos e mensageria.
Containerização e Orquestração:
- Uso de Docker, Kubernetes e práticas de CI/CD para ambientes de dados.

4.2 Exemplos Práticos

Projeto Integrado:
- Construção de um sistema distribuído que integra ingestão, processamento (batch/stream) e orquestração com containerização.

Posts Relacionados:

Engenharia de dados 301 – Sistemas distribuídos e concorrência
Engenharia de dados 301 – Engenharia de Software para Dados

5. Mensageria e Integração em Tempo Real

5.1 Conceitos Teóricos

Sistemas de Mensageria:
- Comparativo entre Kafka, Google PubSub, AWS SQS, RabbitMQ e outros.
Arquiteturas para Integração:
- Ingestão e processamento de dados em tempo real.

5.2 Exemplos Práticos

Implementação Prática:
- Configuração de um sistema de mensageria para ingestão e processamento de eventos.

Posts Relacionados:

Engenharia de dados 301 –Fundamentos de mensageria de dados

6. MLOps

6.1 Conceitos Teóricos

Integração de Dados e Machine Learning:
- Estruturação de pipelines que conectem o processamento de dados com fluxos de ML.
Ferramentas e Práticas:
- Uso de MLflow, Kubeflow, BentoML e outras ferramentas para experimentação, versionamento e implantação de modelos.

6.2 Exemplos Práticos

Projeto de MLOps:
- Criação de um pipeline demonstrando a transição do desenvolvimento até a produção de modelos, com monitoramento de performance e qualidade.

Posts Relacionados:

Engenharia de dados 301 – Fundamentos de MLOps

Módulo de Carreira e Desenvolvimento Profissional

1. Certificações

Principais Certificações:
- Google Cloud Professional Data Engineer
- AWS Certified Data Analytics – Specialty
- Azure Data Engineer Associate
- Databricks Certified Data Engineer
- AWS Certified Data Engineer
Dicas para Certificação:
- Materiais de estudo, simulados e estratégias de preparação.

2. Preparação para Entrevistas

Técnicas e Estratégias:
- Perguntas comuns em entrevistas técnicas e comportamentais para engenheiros de dados.
Exercícios Práticos:
- Resolução de desafios práticos e dicas para apresentação de projetos e experiências.
Recursos Complementares:
- Guias, cursos online e comunidades para troca de experiências.

Sugestões de Livros e Referências Essenciais

Designing Data-Intensive Applications – Martin Kleppmann
Streaming Systems – Tyler Akidau, Slava Chernyak e Reuven Lax
The Data Warehouse Toolkit – Ralph Kimball
Data Pipelines Pocket Reference – James Densmore
Artigos, white papers e documentações oficiais das principais ferramentas (Airflow, Spark, Kubernetes, etc.).

Conclusões

Como atualização rápida, posso dizer que nos últimos meses acabei trabalhando e pesquisando muito sobre ML, modernizei a maior parte da infraestrutura das nossas aplicações. Coloquei algumas coisas pra rodar no meu homelab, que agora tem 2 nós. Fiz alguns projetos internacionais.

E ta ficando cada vez mais difícil me encaixar num rótulo de cargo: Data Engineer, MLOps Engineer, SRE, desenvolvedor, arquiteto. E pra mim isso é ótimo, porque toda essa variedade me ajuda a manter motivado. Comecei a me envolver em discussões e contribuições de alguns projetos open source do meu dia a dia: Airflow, Airbyte, Open Data Discovery, dbt. To fazendo o AirSQL, que é basicamente pra facilitar a minha própria vida com airflow mas acho que pode ser bem útil por aí.

E no próximo semestre eu vou estar até trabalhando como “pesquisador” de ML, na área de visão computacional, que é um dos produtos que a gente ta querendo dar escala. Ganhamos um desafio de aceleração do Google, e além de um orçamento bizarro de créditos de cloud, vamos conseguir mentorias e até usar o espaço Google For Startups aqui em SP.

Introdução à Engenharia de Dados

Cadu Magalhães — Tue, 25 Feb 2025 19:16:41 +0000

Antes de começar com o roadmap, acho importante discutir o que realmente é Engenharia de Dados.

Alguns anos atrás, não existiam todas essas carreiras diferentes em dados; o trabalho era dividido entre Analistas de Negócios (ou BA de Business Analysts, BI de Business Intelligence, etc) e Desenvolvedores. O hype em volta dos dados criou a demanda para os trabalhos especializados, e até hoje (uma ou duas décadas depois), o mercado ainda não se estabilizou.

De forma resumida, a Engenharia de Dados pode ser dividida em duas etapas:

Fundação das operações relacionadas a dados: planejar, desenvolver e dar manutenção para arquiteturas de dados, sistemas de processamentos e etc. Ou seja, ajudar a definir o que será usado (quais ferramentas, plataformas) e como será usado.
Construção de pipelines de dados: a partir de toda a fundação definida, passam a focar no desenvolvimento de pipelines pra baixar, transformar*, mover e disponibilizar dados no melhor formato para o restante das pessoas.

*obs: hoje, é muito comum as empresas separarem a transformação como responsabilidade dos Analytics Engineers, de forma que os Data Engineers focam na fundação

Um pouco de história

Se formos olhar de forma rigorosa, a Engenharia de Dados surgiu no início dos anos 2000, junto com o boom da internet e com criação do conceito de "Big Data" (por muito tempo, o termo era "Big Data Engineer"). Podemos dizer que começou "oficialmente" lá em 2003 quando o Google publicou artigos sobre o seu sistema de arquivos distribuídos, e mais tarde sobre MapReduce. Inspirados nisso, engenheiros do Yahoo criaram o Hadoop em 2006, e a partir daí a história foi se desenvolvendo.

Mas os fundamentos - a ideia de Data Warehouse, de ETL - surgiram muitos anos antes. O termo "Data Warehouse" foi cunhado entre as décadas de 60 e 70, mas foi estabelecido de verdade com a publicação do livro "Construindo um Data Warehouse", de Bill Inmon (considerado pai dos data warehouses).

Outro marco importante foi o surgimento da computação em nuvem, com a AWS em 2006. Essa mudança de paradigma diminuiu os custos relacionados ao tratamento de dados, permitindo escalabilidade e flexibilidade. E a partir daí foram surgindo novas ferramentas para lidar com as necessidades de forma eficiente.

Principais responsabilidades de um Engenheiro de Dados

De forma geral, podemos considerar o seguinte como responsabilidades da área de engenharia de dados

Construir e manter uma infraestrutura de dados escalável
- Definir a arquitetura de dados (Data Warehouse, Data Lake, etc), criando uma estrutura que atenda as necessidades atuais mas que possa escalar para os requisitos futuros
- Implementar os modelos de dados planejados, estruturando os dados de forma que suportem acessos e consultas de forma eficiente
Garantir qualidade, segurança e governança de dados
- Implementar validações e testes para garantir a acurácia, confiança e consistência dos dados
- Estabelecer padrões para uso dos dados, e garantir que estão sendo seguidos.
Otimizar custos
- Otimizar o armazenamento de dados e a performance de consultas e processamentos, usando as melhores práticas de indexação, particionamento e clusterização
Monitoramento e manutenção de pipelines de dados
- Implementar processos de validação, sistemas de alertas e notificação, ferramentas de automação de workflows, de forma que qualquer problema no processamento seja detectado o mais rápido possível

Principais habilidades de um Engenheiro de Dados

Atualmente o mercado exige muito mais do que somente SQL, Python e uma plataforma de nuvem ou banco de dados. Na minha experiência, além desses 3 pilares é preciso ter:

Conhecimentos básicos de engenharia de software: versionamento e git, CI/CD
O básico de linux, redes, infraestrutura. Em alguns casos, uma ferramenta de automação de deploy como terraform ou ansible
Um framework de processamento de dados, como spark
Conhecimento de um orquestrador, sendo Airflow o mais comum
API's, HTTP, web scrapping
Arquitetura de dados, modelagem e conhecimentos básicos de bancos de dados (SQL vs noSQL, por exemplo)
Em casos mais avançados, conhecimento sobre processamento em streaming. Kafka, Flink, além do próprio spark
E mais recentemente, a utilização de uma ferramenta de transformação de dados, como dbt ou dataform

Comparação de carreiras

Cargo	Responsabilidades	Principais habilidades
Engenheiro de dados	Desenvolve e mantém arquiteturas e pipelines de dados.	SQL, Python, plataformas de nuvem
Engenheiro de analytics	Intermediário entre engenharia e análise, focando na transformação de dados brutos para formatos utilizáveis pelos analistas e cientistas	Modelagem de dados, SQL, Python
Cientista de dados	Analisa os dados para extrair insights e construir modelos preditivos	Estatística, Machine Learning, R/Python
Analista de dados	Interpreta dados e provê insights para ajudar em decisões de negócio	Data visualization, SQL, planilhas

Onde esses cargos colaboram

Engenheiros de dados e Engenheiros de analytics: Colaboram para garantir que os dados estão propriamente estruturados e disponíveis para análises
Engenheiros de analytics e Cientistas de dados: Trabalham juntos para transformar os dados em formatos próprios para modelagem e análise
Cientistas de dados e Analistas de dados: Ambos interpretam dados, mas os cientistas de dados costumam desenvolver modelos, enquanto os analistas focam em apresentação de insights

Um exemplo do mundo real

Engenheiro de dados: Configuram uma pipeline que baixa dados de uma ferramenta de análise de interação dos usuários num site
Engenheiro de analytics: Transformam esses dados brutos em tabelas estruturadas com as métricas e dimensões mais importantes
Cientista de dados: Usam os dados estruturados para prever abandono e conversão de usuários
Analista de dados: Interpretam os dados estruturados e os resultados do modelo para fazer recomendações de negócio, como aumentar a retenção de usuários ## Uma análise do mercado de trabalho De acordo com o Market Data Forecast, o mercado global de Engenharia de Dados valeu 75 bilhões de dólares em 2024, e a taxa de crescimento anual projetada é de 17% até 2033, de forma que deve atingir os 88 bilhões de dólares ainda em 2025. Isso tudo devido a alguns fatores levantados pela pesquisa:
A rápida adoção de Big Data no setor bancário e fintechs
O sempre crescente volume de dados
Aumento da demanda para análises e insights em tempo real A pesquisa também aponta a dificuldade de informações em tempo real como uma barreira no crescimento.

Quando falamos de vagas, de acordo com o Tech Job Report da Dice, Engenharia de dados é a 6ª carreira com mais publicações de vagas, tendo um crescimento de 42% de 2021 para 2022. Além disso, SQL e Python são a 2ª e 3ª habilidades mais procuradas em todas as vagas nesse mesmo período.

Infelizmente os dados do Linkedin só são disponíveis com pagamento, mas fazendo uma pesquisa superficial no google, conseguimos encontrar que aproximadamente 1% dos perfis da plataforma (aproximadamente 9 milhões) são de pessoas Engenheiras de Dados. Também conseguimos confirmar que as habilidades mais procuradas são definitivamente SQL e Python.

Concluindo

No fim, a definição de Engenharia de dados acaba sendo feita por cada empresa, de forma que as responsabilidades, atribuições e habilidades vão sempre variar bastante. Mas, de forma geral, os fundamentos costumam ser os mesmos. O próximo post será o planejamento do roadmap de engenharia de dados, destrinchando todos os tópicos que pretendo abordar. Inicialmente o roadmap deve ter tópicos iniciantes e intermediários, mas todos os assuntos serão aprofundados da melhor forma possível. Meu objetivo é não só listar ferramentas e dar exemplos de utilização, mas construir uma boa base de conhecimento teórico e prático com todos os assuntos.

Criação de conteúdo, open source e planos para 2025

Cadu Magalhães — Tue, 18 Feb 2025 15:43:37 +0000

Faz quase 1 ano que não publico nada. Há praticamente 6 meses, minha presença na internet é quase 0.
Apesar disso, continuei indo aos eventos, fiz algumas palestras. E trabalhei muito. Criamos algumas funcionalidades com modelos de ML (processamento de imagem e de texto), conseguimos um "teste" de estresse na prática em produção, com um dos clientes requisitando mais de 80 req/s. Otimizamos nossas pipelines, reduzimos custos, testamos várias ferramentas open source.
Estudei muito sobre desenvolvimento e arquitetura de software, infraestrutura, machine learning, e bastante teoria de engenharia de dados.

Troquei de trabalho, me permiti ter uma rotina que faça melhor pra minha saúde mental. Fiz várias entrevistas pra gringa, até consegui fazer alguns freelances ganhando em dólar.

E mesmo sem energia nenhuma pra publicar, não consigo deixar de pensar que deveria estar produzindo conteúdo pra comunidade. Que deveria colaborar com open source, tirar os meus próprios projetos do papel. E nesse intervalo todo eu me permiti descansar, apesar dessa auto cobrança.

Ao longo desses meses eu estudei formas de tornar meus projetos viáveis. Até pensei em lançar alguns micro saas pra ver se ganho na loteria e faço um dinheirinho. Enfim, tenho muitos planos e não sei por quanto tempo vou me manter na linha.

Projetos Open Source

As vezes eu até começo os meus projetos, mas dificilmente dou continuidade e mantenho eles vivos. Então vou focar nestes dois:

**https://datacareer.guide
- Aqui eu vou centralizar alguns roadmaps. Gostaria muito da ajuda de gente de Ciência e Análise de Dados, então entra em contato se tiver afim de contribuir. Eu mesmo vou construir os roadmaps de Engenharias de Dados e Analytics. A ideia é listar os temas, dividir por "experiência" (iniciante até avançado), e agregar conteúdos sobre cada um dos temas. No meu caso, devo listar alguns dos meus próprios posts por ex.
https://eventos.cadumagalhaes.dev
- Repensei um pouco na infra dele, e estou pensando se não vale a pena migrar o ""backend"" para uma planilha. De qualquer forma, vou cadastrar mais eventos essa semana, e em breve vou resolvendo as issues uma de cada vez. Além disso, também vou contribuir mais ativamente com os projetos que utilizo no dia a dia. Airflow, dbt, cosmos, superset, formbricks, kubernetes e vários outros. Desenvolvi muita coisa localmente que poderiam ser disponibilizadas nos projetos principais.

Criação de conteúdo

Cursos

Tenho visto um grande movimento de bootcamps, cursos, "academy"s de dados, etc. Alguns tem períodos gratuitos, introduções e etc. Mas para mim, conhecimento deve ser gratuito, então não pretendo colocar uma barreira no que produzo.
De qualquer forma, tenho rascunhos de alguns cursos para tirar do papel, e com exceção de algumas coisas muito especializadas (ex: como trabalhar com dados de uma ferramenta paga), tudo será gratuito. Talvez eu faça como nosso colega Teo Calvo, e apresente os cursos ao vivo. Infelizmente, se não tiver audiência eu vou desanimar e lançar em videos gravados mesmo.

Videos

Também tenho várias ideias de produção de conteúdo específica de vídeos: desafios, opiniões, tutoriais, convidar alguns dos meus amigos por ai para ter conversas. Confesso que nesse ponto meu perfeccionismo me atrapalha um pouco, porque gostaria de produzir com qualidade (o que precisa de conhecimento, tempo, equipamento e etc). Vou tentar passar essa barreira e só lançar o que conseguir.

Blog

Meus planos para o blog são de mais consistência. Pretendo ter um post fixo por semana, feito sempre na quarta feira, que vai começar com minha série de fundamentos de engenharia de dados e ficar um bom tempo nisso. Posts mais subjetivos (como este aqui, resumos de eventos, comentários sobre ferramentas, opiniões), posts temáticos ou simplesmente o que me der vontade de publicar, poderão ser publicados em outros dias da semana. O primeiro post já vai ser amanhã, 19 de fevereiro, e está agendado.

Por questões de branding, também vou começar a traduzir meus posts para o inglês. Depois de ter publicado por um mês com consistência, pretendo começar as traduções e postar uma por semana também.

Também pretendo lançar mais de uma newsletter.

A primeira, semanal, vai ser uma curadoria de conteúdos de Engenharia de Dados.
A segunda, mensal, vai ser uma newsletter de eventos do próximo mês e eventos com call for papers aberto. Se eu gostar desse formato, posso acabar fazendo outras. Consumo bastante conteúdo todos os dias, diversas newsletters, artigos e videos, de vários assuntos relacionados à tecnologia.

Comunidade

Quem me conhece sabe que há anos eu digo que não temos uma comunidade de engenharia de dados. Existem comunidades de data science, e várias comunidades de "dados" em geral mas que no fim acabam falando muito de ML.
Só que hoje tenho uma função mais generalista, então tenho dúvida se eu gostaria de focar tanto assim em um único assunto.
Faz bastante tempo que tenho vontade de "lançar" uma comunidade, organizar meetups e outros encontros que não envolvem falar de trabalho. Voltar aos "coding dojos", rodas de conversa e sair um pouco desse modelo de palestra.
Então por enquanto, meu plano é criar uma "marca" para a comunidade, e ter "divisões" dentro dela para assuntos específicos. Engenharia de Dados, DevOps e SRE, Backend ou python. Tudo vai depender das pessoas. E claro, ter encontros pra jogar videogame, jogos de tabuleiro, tocar instrumentos, montar um clube de xadrez ou speedruns; fazer um espaço onde nos juntamos não só pra falar de tecnologia, mas pra de fato ser uma comunidade. Se tudo der certo, devo começar a montar as redes sociais no inicio de março. E claro, aceito ajuda.

Trabalho

Bem, estou muito feliz participando de uma startup em early stage e construindo os produtos do 0. Devo dedicar mais esforço em conseguir freelances e projetos curtos, de preferência internacionais. E apesar de ter saudades das vantagens do CLT, não vou aceitar nada híbrido. Sem falar na quantidade de vagas "pj tipo CLT", que definitivamente não são pra mim.

Concluindo

Enfim, o motivo deste post é me lembrar algumas coisas: que gosto de escrever, independente se alguém vai ler; que minha vontade de produzir conteúdo e ajudar as pessoas não sumiu; que eu posso fazer esse compromisso comigo mesmo e tirar as ideias da minha cabeça.
Me sigam no finado xwitter, bluesky e linkedin, pois são os lugares onde vou divulgar todas essas coisas. Caso queiram ver mais fotos de gatos, eventualmente uma paisagem ou algum video de cover, podem me seguir no instagram também.

Os eventos (de tech) morreram? Vida longa aos eventos

Cadu Magalhães — Tue, 21 May 2024 17:08:30 +0000

Honestamente, os eventos mudaram muito de 5 anos pra cá. EU, Cadu, tenho achado o conteúdo majoritariamente raso. Essa é minha opinião completamente pessoal e não é nenhuma verdade absoluta. Para mim, as grandes conferências viraram isso. Conteúdos rasos, palavras chave pra chamar atenção do grande público. Crypto, metaverso, web3, GenAI, Chat GPT.

Senta que lá vem história

Eu estou na comunidade tech a relativamente bastante tempo. Meus primeiros eventos foram lá em 2013. Fui num arduino day, na BSides, alguns meetups de comunidade.

E por ter entrado tão cedo, eu aprendi muita coisa. Desde o começo eu tive a vontade de devolver conhecimento pra comunidade, porque ali eu tive contato com muita gente incrível e muito conteúdo bom.

Em 2014 eu conheci a Campus Party, e fiquei maravilhado. Um evento enorme, com praticamente 10 palcos diferentes, todos com palestras. Tinha algumas pessoas famosas no palco principal, mas tinha muito conteúdo técnico nos outros. E as comunidades, que improvisavam "palcos" nas suas bancadas na madrugada, onde tinha ainda mais conteúdo. Desde então eu fui campuseiro em praticamente todos os anos. E continuei indo em meetups aleatórios, e todos os eventos que eu pude. Até em hackathons eu fui!

Em 2020 vocês sabem o que aconteceu, e esse ecossistema esfriou. Algumas comunidades continuaram fazendo meetups online, muita gente começou a fazer live. Mas a gente sentiu saudade dos eventos presenciais.

Em 2021 a Campus Party Brasil voltou. Ainda vazia, com bastante distanciamento, mas eles tentaram. Desde então as coisas tem voltado aos poucos. Mas algo ficou diferente. Eu não estava mais achando nenhum conteúdo que me interessasse. Já estava começando a sentir isso em 2020, não da pra dizer que era por experiência.

O conteúdo da grande maioria dos eventos passou a ser muito raso. Das grandes conferências então, ainda mais. O networking sempre foi uma parte importante dos eventos, mas a partir daí passou a ser só isso, pelo menos pra mim. Ver gente conhecida, ver gente "famosa".

Por causa desse incômodo eu decidi que ia começar a palestrar. Ao invés de reclamar no twitter, eu sempre fiz o que achei que fizesse mais sentido: mando várias palestras pros eventos, e dou feedback pra organização quando pedem.

A ameaça fantasma

Mas vamos voltar a raiz: os conteúdos passaram a ser rasos, repetitivos. Muita coisa sobre os mesmos assuntos, as palavras do momento. Em 2019, 2020 muita gente falava de React. "Como fazer seu primeiro site/app com react" era bem comum. Mas ainda tinha alguma variedade. Em 2022 era tudo crypto, metaverso, web3. De 2023 pra cá é GenAI, chatGPT. Eu sei que não fui em todos os eventos, que existem exceções. Mas as grandes conferências viraram isso. O evento mais legal que EU fui em 2023, por conteúdo, foi a CSS Conf, e eu nem sou frontend. Mas o conteúdo foi bom!

E veja bem, não acho que a culpa seja das organizações. Organizar eventos é difícil. Você precisa fazer a conta fechar. Você tem que chamar atenção do máximo possível de pessoas, vender ingresso. Justificar os patrocínios.

Parte da culpa, na minha opinião, é da comunidade. A comunidade que não engaja o suficiente. A comunidade que deixa de submeter assuntos mais complexos (ok, é difícil falar em 15, 30 minutos). Fomos nós que permitimos que os assuntos "do momento" tomassem os eventos; porque deixamos de ir pra assistir conteúdo, porque não incentivamos as pessoas novas a buscarem isso. Porque os eventos precisam fazer malabarismo pra conseguir encher de gente. Porque nós não damos espaço pra diversidade, e ainda permitimos que o mais diverso seja ter painéis "como é ser [insira grupo diverso] na área?"

Uma nova esperança

Mas existem eventos diferentes!

DevOps Days

Conheci a pouquíssimo tempo o devopsdays.

Aqui preciso fazer um disclaimer: DevOps não é um cargo, não é uma área. É uma cultura. É juntar gente de Dev e de Infra (ou "Ops"). E o DevOps Days é pra falar sobre tudo que envolve dev, infra. A maioria dos assuntos acaba sendo relacionada ao que nós consideramos "DevOps", mas o objetivo não é esse.

Enfim, esse é um evento diferente. Ele tem vários momentos dedicados ao networking, mas o mais diferente é que no final tem grupos de discussão sobre vários assuntos. Da comunidade pra comunidade, sem palco, sem destaque. Simplesmente gente trocando ideias sobre um assunto.

Security BSides

E ainda mais recentemente, eu voltei pra Security BSides, que teve aqui em São Paulo. E esse evento é bem diferente da maioria. Primeiro porque é gratuito. É pago completamente pelos patrocinadores. Mas o mais diferente é o formato de conteúdo. Esse ano, tinha "palcos" grandes, salas maiores em que estavam os destaques da programação. Mas além disso, tinha 14 salas pequenas, chamadas de Villages. Nesses villages o conteúdo é muito parecido com aquele que me engajou 10 anos atrás: conteúdo submetido pela comunidade, pra comunidade. Sem se importar com seguidores, tempo de experiência, ou com temas que precisam chamar atenção usando marketing. Era o conteúdo que aquelas pessoas gostariam de ver! E eu vi muita coisa legal. Palestras que me fizeram prestar atenção, ficar interessado.

E pelo que conversei, os eventos da comunidade de segurança são assim. Não tem ninguém muito preocupado com holofotes, é sobre conteúdo.

Outros

Eu sei que alguns outros eventos seguem esse mesmo formato. O TDC por exemplo, tem várias trilhas. E os meetups de comunidade estão tentando voltar. O NodeBR tem trazido assuntos bem diferentes.

O que pode ser diferente?

Organizando

Para as organizações, eu acho que precisamos repensar nos formatos. Um palco é muito pouco. Tem várias formas diferentes de dividir, e isso eu deixo pra virar uma discussão depois. Mas pra um evento grande, precisamos de espaço pra mais gente falar. As janelas de tempo também estão diminuindo, e eu pessoalmente não gosto disso. 15 minutos mal são tempo suficiente pra introduzir um assunto, então seria legal nas agendas dizer o "nível" da apresentação. E na minha opinião, precisamos de transmissão online sempre (eu sei, é difícil).

E uma coisa que sinto muita falta, são os workshops e apresentações com mais engajamento. Fazer as pessoas participarem de fato. Claro que isso precisa de mais tempo, de equipamento e tem várias limitações. Mas eram minha parte preferida quando eu estava começando.

E além disso, nós precisamos descobrir uma forma de centralizar os eventos! Temos o eventosti.dev, do @pokemaobr. Só que esse projeto precisa que as pessoas mandem os eventos. E ainda assim: cada evento vende ingressos num lugar, recebe palestrar num outro lugar, mostra agenda de um jeito diferente.

Participando

Para a comunidade, nós precisamos melhorar muita coisa. Pros meetups voltarem a funcionar, as pessoas precisam aparecer. Nós estamos nos acostumando a esperar menos de 50% dos inscritos nos lugares, isso complica muito a organização. Nós precisamos engajar; não só compartilhar sobre os eventos e meetups, mas engajar com as pessoas. Incentivar as pessoas a participar. Nós estamos deixando o "ciclo" esfriar.

As pessoas mais experientes (e que tem vontade de compartilhar) precisam mandar mais conteúdo. E conteúdos diferentes! Eu sempre penso em mandar assuntos que EU gostaria de assistir (e por isso você nunca vai me ver falando sobre usar GenAI pra fazer seu site etc). E as pessoas menos experientes não precisam ter medo de compartilhar conteúdo. Você pode aprender algo para palestrar. Inclusive é uma ótima forma de aprender um assunto. Você só precisa ter cuidado na pesquisa, e pedir validações de alguém experiente no assunto.

Mas se você tem vontade de palestrar, independente do seu nível, manda pros eventos! E se não tiver ideia de assunto, me chama pra conversar que ajudo a encontrar algo legal.

Já vi algumas páginas de eventos compartilhando pesquisas abertas sobre "quem você gostaria de ver palestrando" ou "que assunto você gostaria de ver". Acho isso legal, e se as pessoas colaborarem pode ajudar também.

O despertar da força

Eu realmente acredito que os eventos podem voltar a dar super certo. E os meetups também. E eu vou continuar participando do máximo de eventos possível, e compartilhando meus conteúdos e experiências quando me derem espaço.

Mas enfim, você concorda com isso ou eu falei um monte de bobagem?

Tudo que você precisa saber sobre Git

Cadu Magalhães — Thu, 05 Oct 2023 22:51:04 +0000

Se você estuda ou trabalha com desenvolvimento, provavelmente já ouviu falar de git, que é uma ferramenta gratuita e open source de versionamento de código (não é só isso, mas vamos simplificar). Quando eu comecei a estudar programação, toda a minha organização e versionamento de códigos era baseada em criar várias pastas no meu computador e ficar replicando várias e várias vezes. Quando queria compartilhar com alguém nós criávamos um .zip da pasta toda e depois gastávamos algumas horas tentando bater alterações pra fazer a entrega no final (meu TCC do técnico está guardado até hoje como tcc_final.zip no OneDrive).

Git veio justamente pra resolver esses problemas: é mais fácil de gerenciar a evolução do seu código ou da sua aplicação; e principalmente, é muito mais fácil colaborar no desenvolvimento.

Tudo que eu preciso saber sobre?

Meu objetivo aqui é simples: prover toda informação disponível para você (desenvolvedor) começar e conseguir usar a ferramenta da vez. Não pretendo responder tudo que você pode ou deveria saber, apenas o necessário.

O que é git
1. Origens e Conceitos
Quando eu deveria usar git
Por onde começar
1. Instalação no Ubuntu
2. Configuração do git
Como funciona
1. Snapshots
2. Checksums
Conceitos fundamentais
1. Commit
2. Branch
Comandos básicos
1. init
2. clone
3. pull
4. branch
5. checkout
6. add
7. commit
8. push
9. status
10. fetch
11. stash
12. merge
Comandos adicionais
1. rebase
2. log
3. revert
4. remote
5. cherry-pick
6. blame
Na prática
Onde encontrar mais informações
Conclusão

You can use this table of contents to help readers navigate your blog post more easily.

O que é git

Numa tradução livre da documentação oficial, git

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

Ele foi criado pelo Linus Torvalds (criador do Linux) em 2005, para ajudar a gerenciar o desenvolvimento do kernel Linux.

A ideia de ser um sistema distribuído é que isso possibilita que várias pessoas ou times possam colaborar num projeto de software enquanto cada um mantém suas próprias cópias locais do projeto todo, incluindo seu histórico. Isso é o oposto do que seria se fosse um sistema centralizado, o que significaria que todos usuários precisariam se conectar a um único e mesmo repositório central.

E um sistema de controle de versão é feito para gravar mudanças em arquivos (ou grupos de arquivos) ao longo do tempo, de forma que você possa recorrer a versões específicas mais tarde. A verdade é que vamos falar aqui de usar no contexto de software, mas isso pode ser usado para basicamente qualquer tipo de arquivo num computador. Então seria muito interessante usar isso mesmo para trabalhos como edição de video, por exemplo.

Ou seja, git existe para te ajudar a acompanhar as mudanças na sua base de código, a colaborar com múltiplas pessoas desenvolvedoras e a garantir que você tem uma forma de backup e recuperação de como era o seu código a qualquer momento; tudo isso além de ter um sistema de branch que permite que possamos trabalhar no código sem afetar o código “principal”.

Um ponto importante, é que git é o sistema, e não está diretamente relacionado com as empresas e softwares Github e Gitlab.

Quando eu deveria usar git

Sempre. Sério, o único motivo que pode justificar a não utilização de git em um projeto, é falta de conhecimento. E pra isso que estou escrevendo isso aqui, então no geral, use sempre.

Mas falando de forma geral, os principais casos de uso são justamente o de trabalhos colaborativos, além do poder de controlar o versionamento em si. Sabe quando você faz um projeto, que está funcionando, ai começa a mexer pra “melhorar” e ele para de funcionar? Com git você consegue voltar no histórico sem depender do seu ctrl+Z.

E apesar de poder usar localmente, é difícil encontrar motivos pra não usar algum host de git (mesmo para os seus projetos pessoais) como o Github, Gitlab ou Bitbucket, já que todos têm planos gratuitos.

Por onde começar

Já que eu espero que você tenha lido sobre como configurar o windows para desenvolvimento, vou dizer como se instala no Ubuntu. Caso precise instalar em outro sistema, a documentação oficial tem exemplos para várias opções.

No nosso caso, basta executar

sudo apt install git

git config

Depois de instalar, idealmente você precisa fazer algumas configurações padrões para garantir o melhor funcionamento. Parte das informações armazenadas pelo git envolvem seu nome e email, por exemplo, para que sejam anexadas ao histórico de alterações. Para configurar essas informações de forma global, você pode usar os seguintes comandos:

git config --global user.name "[seu nome ou nome de usuário]"
git config --global user.email "[seu email]"

Também podemos configurar essas informações em nível de repositório, mas para começar a configuração global é mais do que suficiente.

Como funciona

(não que você precise saber)

Ao invés de tentar armazenar quais alterações são feitas em quais arquivos, Git pensa nos seus dados como uma série de snapshots de um sistema de arquivos. Ou seja, toda vez que você faz um commit (que é a ação de salvar o estado do seu projeto), Git vai basicamente tirar uma foto de como todos os seus arquivos estão naquele momento, e armazenar uma referência a isso. E pra ser eficiente, se não houve nenhuma alteração em algum arquivo, ele não vai ser armazenado novamente. Ao invés disso, o Git vai simplesmente fazer uma referência ao arquivo que já foi armazenado.

Além disso, quase toda operação feita com Git depende somente dos seus recursos e arquivos locais, sem depender muito de informações vindas de outro computador ou de um servidor. Isso faz com que ele seja extremamente rápido e eficiente, além de garantir que mesmo que você esteja offline, vai conseguir trabalhar.

E a forma como Git “mede” as alterações em arquivos, é que eles fazem o processo chamado de checksum. A ideia é que você gera um valor com base no conteúdo do arquivo, e caso o conteúdo se altere, esse valor também é alterado. Isso é uma forma de garantir que Git tenha integridade, já que é impossível que o conteúdo de qualquer arquivo ou diretório seja mudado sem que Git note. (Esses checksums são gerados a partir de um hash SHA-1 , que é uma string de 40 caracteres hexadecimais, tipo assim: 24b9da6552252987aa493b52f8696cd6d3b00373. Quando usar git, vai ver que esses códigos estão presentes em todo lugar, porque é assim que as informações são armazenadas).

Conceitos fundamentais

Commit

Como mencionado brevemente acima, o commit é a ação de salvar o estado atual do seu projeto.

Branch

Apesar do poder do versionamento, as vezes precisamos trabalhar em múltiplas coisas de uma vez. É nesse contexto que as branches (ou ramificações) aparecem. Git consegue armazenar múltiplos estados diferentes do seu projeto através dessas ramificações, que posteriormente podem ser juntadas de acordo com a necessidade.

Comandos básicos

init

Esse é o comando que você executa num diretório para iniciar um novo projeto de git. Ele vai fazer a inicialização básica do sistema.

git init

clone

Caso queira fazer uma cópia de um projeto já existente, você usa esse comando.

git clone [URL do projeto remoto]

pull

É o jeito mais comum de baixar o conteúdo mais recente do repositório remoto, mas é preciso ter cuidado com ele. Quando você executa um pull, além de baixar tudo ele também atualiza o seu conteúdo local para o mais recente, o que pode gerar conflitos.

git pull

branch

É o comando usado para listar, criar ou apagar uma branch.

# Listar todas as ramificações
git branch

# Criar uma nova branch
git branch [nome da branch nova]

# Apagar uma branch
git branch -d [nome da branch]

checkout

Continuando na ideia de branches, esse comando é usado para definir qual é a branch ativa do seu repositório local.

git checkout [nome da branch]

# bonus: criar e trocar para uma branch
git checkout -b [nome da branch nova]

add

Conforme você vai fazendo alterações, você precisa adicionar elas para que sejam armazenadas posteriormente. Você vai usar esse comando quando cria novos arquivos, quando muda o nome deles ou quando altera o conteúdo. É importante entender que isso não vai armazenar o estado, vai apenas colocar os arquivos na “fila”.

## para adicionar um arquivo ou diretório específicos
git add [arquivo ou diretório]
## para adicionar N arquivos ou diretórios especificos
git add [arquivo1] [arquivo2] [diretorio]
## ou para adicionar todos os arquivos alterados
git add --all
## ou
git add *

commit

Para salvar o estado atual do projeto, após ter adicionado os arquivos, fazemos um commit. Ele vai criar uma nova revisão do seu repositório, gerar um novo código e guardar todas as alterações que foram feitas, junto com a informação de quando e por quem foram feitas.

## Para uso interativo, dessa forma você vai ser 
## direcionado para um editor de texto antes de finalizar o commit
## Aqui você deve escrever sua mensagem de commit, com os detalhes que achar necessários.
git commit 

## Caso a mensagem seja curta, ou simplesmente não queira passar pelo editor
git commit -m "[sua mensagem de commit]"

Aqui também fica a recomendação da utilização dos Commits Convencionais, que são uma sugestão de padrão do início da mensagem de commit.

push

É basicamente o contrário do pull, serve para enviar suas alterações locais para o repositório remoto.

# Enviar alterações para uma branch que já existe no remoto
git push

# Enviar alterações para uma branch que foi criada local
git push --set-upstream [nome do remoto] [nome da branch]
# geralmente é usado como git push --set-upstream origin [branch]

status

É usado para comparar o estado atual do seu repositório local com o último estado armazenado, e com o repositório remoto (caso haja).

git status

fetch

De forma semelhante ao pull, serve para baixar mudanças feitas no projeto remoto. A diferença é que dessa forma elas não serão aplicadas automaticamente para o seu repositório local, você vai precisar definir o que fazer com as alterações na sequência.

git fetch

stash

As vezes precisamos mudar de branch depois de já ter trabalhado em uma, mas antes que as coisas estejam prontas o suficiente para virar um commit. Nesse contexto podemos usar o stash, que vai armazenar temporariamente as modificações na área de stash, que é essencialmente é uma pilha (uma lista onde os elementos são empilhados).

# Para "guardar" os arquivos no stash
git stash

# Para listar todos os existentes
git stash list

# Para apagar um stash da pilha
git stash drop

# Para recuperar um stash
git stash apply

# Para aplicar/recuperar e remover da pilha (eu costumo usar esse)
git stash pop

merge

Depois de trabalhar em múltiplas branches, provavelmente você vai precisar unificar as coisas em algum momento. É ai que entra o merge, que vai ser responsável por juntar 2 branches em uma única.

git merge [branch de destino] [branch de origem]

Isso vai criar um commit de merge na branch de destino, e vai atualizar comparar apenas as últimas versões de cada um. Esse é um método interessante porque ele não vai mexer no histórico de nada, vai apenas criar um novo commit para garantir que as coisas estejam atualizadas.

Comandos adicionais

rebase

O objetivo é parecido com o do merge, mas o rebase reescreve o histórico de commits do projeto, de forma que ele move a sua branch para o final do histórico, criando novos commits para cada commit da branch de origem, de forma que o histórico do seu projeto vai ficar muito mais “limpo”. Isso porque ele não tem os commits de merge (que são feitos quando você usa git merge , e no final o histórico do seu projeto fica perfeitamente linear (enquanto com merge as coisas podem ficar difíceis de acompanhar, dependendo da complexidade do projeto). É importante deixar claro que com isso você perde um pouco da rastreabilidade (pois está sempre reescrevendo o histórico) e você perde o contexto de quando as alterações foram “aceitas” na sua branch principal.

git checkout [branch de destino]
git rebase [branch de origem]

Esse é um comando que pode impactar bastante o trabalho colaborativo, então antes de pensar em usar é importante saber se tem mais alguém trabalhando na branch em que você vai mexer. Isso porque vão acontecer vários conflitos entre a sua versão (a com rebase) e a versão que a pessoa pode estar trabalhando. Algumas pessoas chamam isso de “Golden Rule do rebase”.

log

Esse é o comando que você pode usar para ver o histórico de commits do repositório.

git log

revert

Esse é um comando para desfazer mudanças, mas que ao invés de modificar os commits já feitos no histórico, ele vai criar um novo commit desfazendo as mudanças. Podemos considerar que é uma alternativa segura ao git reset, que tem uma chance de te fazer perder o histórico.

git revert [commit hash]

# Também podemos dizer quantos commits a partir do último serão revertidos
git revert HEAD~[numero de commits]

remote

Esse é o comando que você usa pra criar a conexão entre o seu repositório local e um repositório remoto.

git remote add [apelido do repo remoto] [url do repositório]

# Geralmente vai ser algo como
git remote add origin <https://github.com/>[nome de usuario]/[nome do repo]

cherry-pick

Imagina que você e uma outra pessoa estão trabalhando em duas branches diferentes, mas que a outra fez um commit com uma alteração que você também pode usar, e você não quer reescrever algo que já foi feito. O cherry-pick permite que você selecione qualquer commit de uma branch, e aplicá-lo a uma outra branch, sem ter que se preocupar com o histórico todo.

git cherry-pick [commit hash]

blame

É o comando utilizado para dizer qual usuário fez quais alterações num determinado arquivo.

git blame [nome do arquivo]

Na prática

Apesar de achar importante você conhecer, entender e saber usar a linha de comando, a verdade é que você provavelmente não precisa. A maioria das IDE’s ou editores de código tem extensões para lidar com git e te prover uma interface que facilita bastante a utilização. Também existe o Github Desktop mas eu pessoalmente não gosto muito dele.

Uso a maior parte das coisas direto na extensão de git padrão do VS Code, que te da um resumo das alterações atuais do repositório, uma lista de commits, de branches e de stashes e honestamente tudo que você pode precisar. Isso facilita muito, principalmente na hora de resolver conflitos.

Ele também acrescenta o git blame no próprio editor, fazendo ficar bem fácil entender o histórico do projeto.

Eu só uso a extensão padrão, mas se você tiver recomendações de extensões, fique a vontade pra acrescentar nos comentários.

Onde encontrar mais informações

A melhor fonte é provavelmente a oficial, que é onde eu costumo buscar referências (e o que serviu de inspiração pra boa parte do que está aqui):

Git Book (em PT-BR): https://git-scm.com/book/pt-br/v2
Git Book: https://git-scm.com/book/en/v2

Também gostei bastante do conteúdo da Atlassian, que é a empresa criadora do BitBucket

https://www.atlassian.com/git/tutorials

E como não pode faltar, também tem conteúdo da LINUX Tips sobre git:

Descomplicando o Git: https://www.youtube.com/watch?v=_aj3hsEh9iw
Aulão de certificação do gitlab: https://www.youtube.com/watch?v=SMzaAP09BD4

Conclusão

A verdade é que eu fiquei anos usando git e só sabendo git add, git commit, git pull e git push. Isso é tudo que você precisa pra um projeto simples, e usando alguma extensão com interface gráfica você só precisa entender as ações e como executá-las na interface que estiver usando.

Mas conforme vamos trabalhando, passando por projetos de maior complexidade ou simplesmente precisando fazer coisas em grupo, os conflitos e erros começam a acontecer e aí precisamos entender melhor o poder dessa ferramenta.

Não espero que ninguém saia desse post sabendo usar tudo isso, mas aqui tem uma introdução de tudo que eu gostaria de saber quando comecei. Saber quando usar qual comando vem da utilização na prática, então minha recomendação é sempre que você comece. E novamente, não consigo pensar em um motivo pra não usar git em qualquer projeto de desenvolvimento, seja pessoal, de estudos, de faculdade ou de trabalho.

Me diz o que você achou desse tipo de post, e se você gostaria que isso virasse um vídeo no Youtube! Independente do resultado, semana que vem vou falar sobre RegEx.

Espero que isso tenha sido útil para alguém, até a próxima!

How to setup a PostgreSQL database with Docker Compose

Cadu Magalhães — Fri, 22 Sep 2023 14:07:59 +0000

When I started learning about databases, Docker didn't even exist yet. So I spent hours trying to make both the database engine and the workspace interface to work, and there are so many little details in the setup that I'm sure you'll find thousands of articles and videos teaching how to do it in your operating system.

But it's 2023 and containers are a common thing to developers, and honestly you don't even need to understand them to use them. All you need to know is how to install it (and for this, you can check the Install Docker Engine tutorial from docker themselves) and how to run it.

Prerequisites

Docker CLI
Docker Compose
a browser

It's supposed to be easy so that's all.

Setting up

You'll need two files to make this work.

docker-compose.yml

Docker Compose is a tool made to define and run multi-container applications. All you need to do is define your services, do some setups and run it.

version: '3.8'
services:
    postgres:
        image: postgres:15
        environment:
            - POSTGRES_USER=postgres
            - POSTGRES_PASSWORD=password
        volumes:
            - postgres-db-volume:/var/lib/postgresql/data
        ports:
            - 5432:5432
        networks:
            - postgres-db-network
    pgadmin:
        image: dpage/pgadmin4
        environment:
            PGADMIN_DEFAULT_EMAIL: 'teste@teste.com'
            PGADMIN_DEFAULT_PASSWORD: 'teste'
        ports:
            - 16543:80
        volumes:
            - ./servers.json:/pgadmin4/servers.json
        networks:
            - postgres-db-network

volumes:
    postgres-db-volume:
        driver: local
        driver_opts:
            type: none
            o: bind
            device: ./data
networks:
    postgres-db-network:
        driver: bridge

Here we are using two containers:

one for the database itself, which is based on the Postgres 15 image. We also define the port for the database, a volume and some environment variables to set the default user and password for our connection.
the other is for pgAdmin, which is a Postgresql database administration tool. It is also open source, and this way we can manage and interact with our databases using the browser. You can see that we set the port to 16543. This means you'll access it by typing localhost:16543 in your browser. You can change this port, but I like to use a number that probably won't be used for anything else.

servers.json

We don't actually need this file, because in pgAdmin you can use the interface to configure your connection (and set the host, port, user and password). But since I want to make this easier, we use this file to pass these options that will be loaded when our container starts.

{
  "Servers": {
      "1": {
          "Name": "example",
          "Group": "Servers",
          "Host": "postgres",
          "Port": 5432,
          "MaintenanceDB": "postgres",
          "Username": "postgres",
          "PassFile": "/pgpass",
          "SSLMode": "prefer"
      }
  }
}

Running it

With both of these files created, all you need to do is go to their directory and run

docker compose up

This will download the images and start both containers with everything as described in our docker-compose.yml, while logging everything in your terminal. If you don't want that, you can just run it detached with the -d flag

docker compose up -d

This way your containers will be running in background.

To stop the containers, you can use Ctrl+C in case it's running attached to your terminal session, or you can run

docker compose down

Using it

While your containers are running, you'll go to localhost:16543 in your browser and access the pgAdmin dashboard. The first time you open it you'll need to log in with the credentials we set up in our docker-compose file. If you didn't change it, it's teste@teste.com and the password is teste.

Once you're logged in, you can access the connections by clicking Servers at the menu on the right. The first time you open it, it will ask you for the password of the connection. This is also in the docker-compose, and in our example it is password.

Once you are connected, you can right-click on Databases and create your own. In case you're not used to Postgresql, it has the concept of "schemas", and that's where you'll find your tables.

After this point, you can just use it as you want. You can right-click your database and click on Query Tool to write and run your SQL scripts

That's all, hope this helps someone and follow me for more content. If you like it, share it with someone you think might need this.

Tudo que você precisa saber sobre SQL

Cadu Magalhães — Fri, 22 Sep 2023 12:39:57 +0000

SQL é uma linguagem de manipulação e consulta de dados, que é usada em diversas ferramentas diferentes e que nos permite interagir com os bancos de dados sem a necessidade de muitos conhecimentos em linguagem de programação. Hoje a linguagem é um requisito chave em todas as carreiras da área de dados, mas também é um conhecimento muito importante para pessoas desenvolvedoras de backend.

Pra ser sincero, esse assunto é super relativo e as suas necessidades podem variar de acordo com o tipo de trabalho que vai fazer. Vou descrever algumas coisas intermediárias e focar em boas práticas de escrita de consultas, que acredito ser o mais importante. A partir do entendimento básico, a habilidade mais importante passa a ser conseguir usar as documentações da linguagem e das ferramentas para conseguir fazer o que você precisar.

Tudo que eu preciso saber sobre?

Tudo que eu preciso saber sobre?
Table of contents
O que é SQL
1. Variantes de SQL
Quando eu deveria usar SQL
Por onde começar
1. SQL Bolt
2. DB Fiddle
3. BigQuery
4. PostgreSQL + pgAdmin + Docker
A linguagem
DDL
1. CREATE
2. DROP
3. ALTER
4. TRUNCATE
DML
1. INSERT
2. UPDATE
3. DELETE
DQL
Sintaxe básica
1. SELECT
2. FROM
3. WHERE
4. LIKE
5. ORDER BY
6. LIMIT
7. OFFSET
8. UNION
Joins
1. INNER JOIN
2. LEFT JOIN
3. RIGHT JOIN
4. FULL OUTER JOIN
5. CROSS JOIN
6. Funções de agregação
7. COUNT
8. SUM
9. AVG
10. MAX
11. MIN
12. GROUP BY
13. HAVING
Funções condicionais
1. IF
2. CASE
Funções de texto
1. LOWER
2. UPPER
3. CONCAT
Subconsultas
CTE’s
Ordem de operações do SELECT
Outras coisas
Onde encontrar mais informações
Conclusão

O que é SQL

SQL é a sigla para Structured Query Language, ou em tradução livre, Linguagem de consulta estruturada. Isso ajuda a entender o principal objetivo, que é consultar dados. Apesar disso, é possível fazer muito mais coisas utilizando SQL.

De forma mais geral, SQL é usada para consultar e manipular dados em bancos de dados relacionais, além de gerenciar e manter as estruturas de dados (como tabelas, por exemplo).

É uma linguagem declarativa, o que significa que você descreve quais são os resultados que você espera, e não exatamente como o computador deve calcular ou retornar eles.

Variantes de SQL

Existem vários “dialetos” diferentes de SQL, que aproveitaram o padrão e estenderam suas funcionalidades de acordo com o ponto de vista de algumas empresas específicas. A maior parte da sintaxe é compartilhada, e a não ser que você queira trabalhar como pessoa administradora de banco de dados de uma empresa que usa várias ferramentas distintas, você provavelmente não precisa aprender todas. Mas é importante entender que se pegarmos os principais bancos de dados do mercado (Microsoft SQL Server, PostgreSQL, MySQL, Oracle), cada um vai ter funções e pedaços de sintaxe levemente diferente dos outros.

Quando eu deveria usar SQL

Bom, se você estiver usando um banco de dados relacional, provavelmente vai precisar usar SQL. Mesmo que você esteja usando uma biblioteca intermediária na sua linguagem (geralmente são chamadas de ORM, e permitem a utilização do banco de dados quase sem depender de SQL. Sequelize em NodeJS e SQLAlchemy em python são alguns exemplos), nem toda manipulação é traduzida para a biblioteca.

Nós poderíamos ir um passo atrás e questionar quando deveria usar um banco de dados relacional, visto que existem diversos tipos diferentes de bancos de dados, mas é um assunto extenso e pretendo falar sobre todos eles no futuro.

Ou seja, a utilização de SQL provavelmente vem da definição da ferramenta que está sendo utilizada no seu time.

E apenas para encerrar esse tópico, queria ressaltar que é possível usar SQL (ou algo muito parecido) em ferramentas que não foram feitas para isso. Dentro do framework Spark, de processamento de dados, você pode escolher usar SQL ao invés da API de dataframes na linguagem usada (geralmente python, por ex). E o meu exemplo preferido, é possível usar um “pseudo-SQL” em planilhas do Google para consultar seus dados. Também vou escrever sobre isso em breve.

Por onde começar

Por ser uma linguagem declarativa, a melhor forma de aprender é na prática. Por isso, na minha opinião, para começar é importante conseguir um local para executar suas consultas. Então vou trazer 4 opções:

SQL Bolt

O SQL Bolt é um bom começo, apesar de limitado. Além de ter conteúdo sobre a sintaxe, ele oferece alguns problemas simples para ser resolvidos, de forma que você não precisa se preocupar em configurar um banco de dados.

DB Fiddle

O db fiddle é um ótimo jeito de praticar SQL em geral, mas ele não tem tabelas prontas para você utilizar. Testei usar o Chat GPT e pedir para ele descrever tabelas e exercícios, e ele conseguiu atender bem a necessidade. Você pode descrever quais tabelas quer, quais campos cada uma deve ter e pedir que ele gere o SQL para criar as tabelas e preenchê-las com dados.

BigQuery

Quem me conhece sabe que é uma das minhas ferramentas preferidas, porque é possível fazer muita coisa com ele. O BigQuery é a ferramenta de Data Warehouse da Google Cloud, e além de oferecer uma cota gratuita (1 tb de dados processados, 10 gb de dados armazenados), ele também conta com uma série de datasets públicos que podem ser utilizados para estudos. Lá encontramos dados de github, da wikipedia, dados de tráfego aéreo e taxis dos EUA e mais uma dezena de coisas diferentes.

PostgreSQL + pgAdmin + Docker

Um dos motivos de ter feito o post sobre Docker tão cedo, é que ele passa a ser requisito para facilitar nossa vida e nossos estudos.

Nesse repositório do github deixei os arquivos e uma explicação de como utilizar.

Para usar, você só precisa de um docker-compose.yml

# docker-compose.yml
version: '3.8'
services:
    postgres:
        image: postgres:15
        environment:
            - POSTGRES_USER=postgres
            - POSTGRES_PASSWORD=password
        volumes:
            - postgres-db-volume:/var/lib/postgresql/data
        ports:
            - 5432:5432
        networks:
            - postgres-db-network
    pgadmin:
        image: dpage/pgadmin4
        environment:
            PGADMIN_DEFAULT_EMAIL: 'teste@teste.com'
            PGADMIN_DEFAULT_PASSWORD: 'teste'
        ports:
            - 16543:80
        volumes:
            - ./servers.json:/pgadmin4/servers.json
        networks:
            - postgres-db-network

volumes:
    postgres-db-volume:
        driver: local
        driver_opts:
            type: none
            o: bind
            device: ./data
networks:
    postgres-db-network:
        driver: bridge

E nesse exemplo, criei o arquivo servers.json para que você não precise fazer a configuração na interface:

{
  "Servers": {
      "1": {
          "Name": "example",
          "Group": "Servers",
          "Host": "postgres",
          "Port": 5432,
          "MaintenanceDB": "postgres",
          "Username": "postgres",
          "PassFile": "/pgpass",
          "SSLMode": "prefer"
      }
  }
}

Depois, basta executar o comando docker compose up no diretório. Isso vai criar 2 contêineres: um responsável pelo banco de dados, e que está disponível na porta 5432 (Ele também tem um volume montado na pasta data . Isso é um bônus caso você queira que os seus dados persistam no disco, e não só no volume do docker). E um container com o pgdamin, que é uma ferramenta open source de utilização do postgres.

Então basta acessar o endereço localhost:16543 no seu navegador, fazer login no pgadmin, e abrir a opção Servers no menu da esquerda. Um popup pedindo a senha do banco de dados deve aparecer, basta preencher e confirmar.

Com esse setup, você deve conseguir fazer qualquer curso de bancos de dados sem grandes problemas.

A linguagem

Antes de continuar, precisamos esclarecer uma coisa. SQL pode ser dividido em 5 pedaços:

DDL - Data Definition Language, ou Linguagem de Definição de Dados. São os comandos para gerenciar os objetos do banco de dados.
DML - Data Manipulation Language, ou Linguagem de Manipulação de Dados. São os comandos que gerenciam os dados dentro das tabelas.
DQL - Data Query Language, ou Linguagem de Consulta de Dados. São os comandos para consultar os dados.
DTL - Data Transaction Language, ou Linguagem de Transação de Dados. São comandos específicos para controlar transações, que não é um assunto que vou tratar hoje.
DCL - Data Control Language - Linguagem de Controle de Dados. São os comandos que controlam os acessos ao banco de dados e seus recursos. Também não vamos falar sobre isso.

Essas divisões podem ser diferentes em alguns materiais (alguns livros consideram o SELECT como DML e não como uma etapa completamente separada, o DQL). E algumas ferramentas não tem todas essas etapas. Então daqui pra frente, vamos falar brevemente de DDL e DML dando um resumo e exemplo dos principais comandos de cada um. No final vamos detalhar DQL, que vai ser a parte mais extensa.

E outra coisa importante: normalmente escrevemos as palavras chave de SQL em maiúsculo. Isso não é obrigatório, mas ajuda a separar o que é palavra reservada do que não é. Então daqui pra frente, toda palavra em maiúsculo você pode considerar como palavra especial ou função

DDL

CREATE

O comando CREATE é usado para criar objetos de banco de dados, como tabelas ou views, por exemplo.

Para criar uma tabela, precisamos descrever todas as suas colunas, os seus tipos e mais algumas regras (por ex, se aquele campo pode ser vazio ou não). No exemplo abaixo criamos uma tabela “clientes”, com os campos id, nome e email. Lembrando que como estou usando o postgresql, temos algumas coisas especificas, como o tipo SERIAL no id abaixo.

CREATE TABLE clientes (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(50),
    email VARCHAR(100)
);

Também podemos criar views, que são uma forma de armazenar consultas prontas no nosso banco de dados. Para isso, a sintaxe é como abaixo:

CREATE VIEW consulta_clientes AS 
SELECT nome FROM clientes;

DROP

O comando DROP é usado para excluir objetos de banco de dados, como as tabelas. Veja que não estamos falando de apagar os dados, mas a tabela em si.

DROP TABLE clientes;

ALTER

O comando ALTER é usado para modificar a estrutura de objetos de banco de dados já existentes, como adicionar ou remover colunas de uma tabela.

ALTER TABLE clientes
ADD telefone VARCHAR(20);

TRUNCATE

O comando TRUNCATE é usado para remover todos os dados de uma tabela, mas mantendo a estrutura da tabela.


TRUNCATE TABLE clientes;

DML

INSERT

O comando INSERT é usado para adicionar novos registros a uma tabela.

INSERT INTO clientes (nome, email)
VALUES ('João', 'joao@example.com');

É interessante notar que podemos inserir mais de uma linha de uma vez:

INSERT INTO clientes (nome, email)
VALUES ('Joana', 'joana@example.com'),
('James', 'james@example.com');

E também podemos inserir numa tabela o resultado de uma consulta. Por exemplo, se tivermos uma tabela clientes_backup

INSERT INTO clientes (SELECT id, nome, email FROM clientes_backup);

UPDATE

O comando UPDATE é usado para modificar os registros existentes em uma tabela. Tanto para o UPDATE quanto para o DELETE, é muito importante filtrar em quais dados estaremos mexendo, pois esses comandos podem alterar todos os dados da tabela se usados sem cuidado. A sintaxe do update é a seguinte:

UPDATE clientes
SET nome='James Suco de Fruta', email='james_suco@example.com'
WHERE email='james@example.com'

Veja que agora temos a palavra chave SET, que é usada para escolher quais colunas iremos alterar e quais serão os novos valores. Aproveitei para deixar no exemplo a alteração de duas colunas, para mostrar como fica a sintaxe.

Além disso, aqui vemos pela primeira vez a utilização do WHERE, que é a forma de filtrar dados no SQL. O legal do SQL é que tendo um conhecimento básico de inglês, conseguimos entender exatamente o que está sendo feito. Vou detalhar melhor as condições de WHERE quando falarmos de SELECT, então por hora isso é tudo.

DELETE

O comando DELETE é usado para remover registros de uma tabela. E ressaltando mais uma vez, é extremamente importante filtrar os dados quando for utilizar esse comando. Um delete sem WHERE é equivalente a apagar todos os dados da tabela.

DELETE FROM clientes
WHERE id = 5;

DQL

A princípio, o DQL tem somente um comando: SELECT. Mas vamos aproveitar esse pedaço para falar sobre a estrutura de uma consulta e das funções disponíveis.

Sintaxe básica

SELECT 
  nome AS nome_cliente
FROM 
  clientes
WHERE
  sexo="m"
ORDER BY id
LIMIT 2

SELECT

É usado para selecionar os dados (é). Os dados são retornados num formato tabelar. Aqui você pode descrever quais são as colunas que quer selecionar, pode acrescentar colunas novas no resultado, utilizar condicionais e agregações (descritos mais abaixo), dar novos nomes às colunas. A sintaxe é simples e a melhor forma de entender é testando, então recomendo novamente dar uma olhada no SQL bolt.

De forma geral:

* vai retornar todas as colunas
coluna vai retornar uma coluna com o mesmo nome.
coluna AS apelido_coluna vai mudar o nome da coluna somente no resultado
DISTINCT pode ser usado para trazer uma combinação de valores distintos das suas colunas
* EXCEPT(coluna_2, coluna_3) pode ser utilizado para retornar todas as colunas menos algumas específicas.

FROM

Aqui definimos de onde vamos consultar. A forma como o endereço é passado depende da ferramenta de banco de dados, no caso do postgres você pode passar somente o nome da tabela (caso esteja usando o schema public, que é o padrão), ou o formato schema.tabela . Os JOIN (que estão descritos mais abaixo) também fazem parte do FROM, pois são uma forma de acrescentar mais tabelas no resultado.

WHERE

Usamos o WHERE para filtrar os resultados com base numa condição pré-definida. Para isso precisamos saber os operadores condicionais básicos:

> (maior): altura>150
< (menor): idade<25
= (igual): email='cadu@cadumagalhaes.dev'
!= ou <> (diferente): nome!='Cadu'
>=(maior ou igual): idade>=18
<= (menor ou igual): sapato<=40
BETWEEN (entre): idade BETWEEN 18 AND 25
IN () (valor pertence a lista): cidade IN ('SP','RJ')
LIKE detalhes abaixo

E os operadores lógicos:

AND : idade>12 AND cidade='Sao Paulo'
OR : cidade='Sao Paulo' OR cidade='Rio de Janeiro'

LIKE

O LIKE tem uma estrutura diferente e por isso achei melhor deixar separado. A principio, ele pode ser usado como o =:

WHERE nome LIKE 'Carlos'

E nesse caso, vai trazer somente caso o resultado seja exatamente igual. Mas o like tem 2 operadores:

% : pode ser substituido por qualquer coisa em qualquer quantidade
_ : pode ser substituido por uma ocorrência de qualquer coisa

Por exemplo, caso queiramos saber todos os nomes que começam com Carlos, fazemos assim:

WHERE nome LIKE 'Carlos%'

Nesse caso, eu leio como “Carlos qualquer coisa”, porque é o que ele vai retornar. Se for somente Carlos, retorna. Se tiver outras coisas, como “Carlos Eduardo”, também retorna. O valor “Roberto Carlos” não seria retornado nesse caso, pois não começa com nossa condição.

Se quisermos saber todos os nomes que terminam com Silva, fazemos assim:

WHERE nome LIKE '%Silva'

De forma semelhante, não importa o que há antes, desde que termine com Silva.

Se quisermos saber todos os nomes que contém Carlos, fica assim:

WHERE nome LIKE '%Carlos%'

Note que agora colocamos o símbolo de porcentagem antes e depois do texto que estamos buscando.

Para entender o outro operador, vamos imaginar que temos uma coluna que tem as iniciais dos nomes das pessoas. Temos o Cadu Magalhães (CM), o Cristiano Ronaldo (CR7), o Ronaldo Fenômeno (R9), o Roberto Carlos (RC) e o Neymar (NJR)

Se por algum motivo nós quisermos somente os resultados em que o R seja a segunda letra, a nossa consulta ficaria assim:

WHERE iniciais LIKE '_R%'

Dessa forma, estamos limitando que só pode haver um caractere antes do que estamos procurando. Honestamente nunca precisei usar esse operador, mas pouca gente fala sobre isso então achei legal trazer.

ORDER BY

Usado para definir a ordenação dos resultados em ordem ascendente ou descendente, com base em uma ou mais colunas.

ORDER BY idade
#ou
ORDER BY idade, genero, cidade DESC

Por padrão, vai ordenar de forma ascendente. Mas podemos especificar passando ASC ou DESC.

LIMIT

Usado para definir a quantidade de resultados que deve ser retornada. Por ex, para saber o top 3 de uma competição:

SELECT nome 
FROM resultados 
ORDER BY nota
LIMIT 3

OFFSET

Geralmente é usado junto com o LIMIT quando precisamos retornar algum número que não esta exatamente no topo. Serve para dizer quantas linhas do inicio devem ser puladas antes de retornar. Por exemplo, se eu quiser uma consulta que retorne somente o segundo colocado da competição:

SELECT nome 
FROM resultados 
ORDER BY nota
LIMIT 1
OFFSET 1

UNION

UNION é usado para juntar tabelas de forma vertical, ou seja, empilhar uma em cima da outra. É uma forma de aumentar o número de linhas, e não de colunas.

Por exemplo, se temos 2 tabelas de clientes e queremos juntar o resultado:

SELECT * FROM clientes_1
UNION 
SELECT * FROM clientes_2

Esse comando tem uma variação, que é o UNION ALL. A diferença é que por padrão, o UNION vai juntar somente resultados únicos. Então se uma mesma linha está nas duas tabelas, vai aparecer uma única vez. Quando usamos UNION ALL, todas as linhas são retornadas, incluindo duplicidades.

Joins

A partir daqui as coisas começam a ficar confusas de novo. Temos 5 tipos de join, e é bem difícil explicar as diferenças em texto. Join é uma forma de juntar duas tabelas horizontalmente. Ou seja, vamos colocar uma tabela do lado da outra, de acordo com uma condição pré definida. Para isso, vamos considerar sempre que a tabela que colocamos no nosso FROM está na esquerda, e a tabela que estamos dando JOIN está na direita. Isso vai facilitar o entendimento de algumas coisas.

INNER JOIN

Retorna somente as linhas em que a condição de join deu resultado nas tabelas dos dois lados.

LEFT JOIN

Retorna todas as linhas da tabela da esquerda, e preenche na direita somente o que deu resultado. Quando não houver match, vai preencher com null. É um bom jeito de acrescentar informações nas tabelas.

RIGHT JOIN

O contrário do LEFT JOIN, é só uma questão de referencial.

FULL OUTER JOIN

Retorna todas as linhas, não só as que deram match mas as que não deram também, dos dois lados.

CROSS JOIN

Vai juntar cada uma das linhas da primeira tabela com todas as linhas da segunda tabela. Ou seja, vai retornar um “produto cartesiano”* das duas tabelas.

A melhor forma de entender joins é com exemplos, e acho que esse é o tipo de coisa que fica muito mais confusa se for somente por texto. Se acharem necessário, posso revisar esse post e acrescentar exemplos para cada um deles, mas por enquanto vou economizar esses minutos de leitura (e possivelmente horas de escrita). Então comenta aqui no post se quiser que eu tente explicar melhor os joins :)

Funções de agregação

COUNT

Serve para contar a quantidade de resultados com base na agregação definida. Por exemplo, se eu quiser saber quantas pessoas de cada gênero tem na minha tabela de clientes:

SELECT
  genero,
  COUNT(*) as total
FROM clientes
GROUP BY genero

Veja que no exemplo eu acrescentei o GROUP BY. Quando começamos a agregar os dados, precisamos garantir que as nossas dimensões também estejam agregadas. Se não agruparmos, o banco de dados retornará um erro por não saber o que fazer com a coluna de gênero.

Também podemos removê-la e contar o total de clientes:

SELECT 
  COUNT(*) as total
FROM clientes

E nesse caso não precisamos agrupar por outras colunas.

SUM

Serve para somar o valor de uma determinada coluna e retornar o total.

SELECT
  cliente,
  SUM(receita) AS receita_total
FROM 
  compras
GROUP BY clientes

Importante ressaltar que só pode somar valores numéricos.

AVG

Calcula o valor médio de uma coluna.

SELECT
  cliente,
  AVG(receita) AS receita_media
FROM 
  compras
GROUP BY clientes

MAX

Retorna o maior valor de uma coluna.

SELECT
  cliente,
  MAX(receita) AS maior_receita
FROM 
  compras
GROUP BY clientes

MIN

Retorna o menor valor de uma coluna.

SELECT
  cliente,
  MIN(receita) AS menor_receita
FROM 
  compras
GROUP BY clientes

GROUP BY

Bom, já falei ali atrás, mas o principal uso do GROUP BY é ajudar a retornar as funções de agregação junto de uma dimensão. Você também pode usar o GROUP BY pra deduplicar (literalmente agrupar) linhas nas colunas.

HAVING

Um detalhe importante aqui, é que nós não conseguimos usar WHERE para filtrar o resultado de agregações. Por exemplo, se eu quiser trazer somente os clientes cuja receita média é maior que 100, isso não pode ser feito no WHERE.

Para isso existe o HAVING, que permite que façamos filtros nos resultados com base nas agregações. E vou aproveitar para mostrar como usar tudo isso de uma vez:

SELECT
  cliente,
  SUM(receita) AS total_receita,
  AVG(receita) AS media_receita,
  COUNT(*) AS numero_pedidos
FROM
  pedidos
  LEFT JOIN clientes USING(cliente_id)
WHERE cidade='Sao Paulo'
GROUP BY cliente
HAVING numero_pedidos<10
ORDER BY total_receita
LIMIT 3

Essa consulta traz o top 3 clientes que mais gastaram em São Paulo e que fizeram menos de 10 pedidos, com o detalhe de que a informação da cidade não está disponível na tabela de pedidos.

Funções condicionais

Tecnicamente as condicionais também são funções de agregação

IF

Serve para definir o valor de uma coluna com base numa condição simples, com apenas 2 possíveis resultados.

IF(condicao, valor se true, valor se false) AS coluna

Exemplo:

IF(pais='BR', 'pessoa brasileira', 'pessoa estrangeira') AS nacionalidade

CASE

Serve para definir o valor de uma coluna com base em qualquer condição, com N possíveis resultados, além de um valor padrão caso nenhuma condição seja verdadeira.

CASE
  WHEN condicao_1 THEN valor 1
  WHEN condicao_2 THEN valor 2
  ELSE valor default
END AS coluna

Exemplo:

CASE
  WHEN pais='BR' THEN 'pessoa brasileira'
  WHEN pais='EUA' THEN 'pessoa americana'
  ELSE 'outros'
END AS nacionalidade

Funções de texto

LOWER

Transforma o valor de uma coluna em minúsculas.

LOWER(coluna) as coluna

UPPER

Transforma o valor de uma coluna em maiúsculas.

UPPER(coluna) as coluna

CONCAT

Concatena (junta) valores de texto em uma única coluna.

CONCAT(valor_1, 'string', valor_2) as coluna

Provavelmente existem outras centenas de funções, essas são as mais comuns para tratamentos simples de dados.

Subconsultas

Honestamente eu tenho muito receio com o conceito de subconsultas porque a leitura pode ficar bem ruim. Para quem conhece Javascript, isso me lembra um pouco o callback hell de quando não tinhamos async await. A ideia é que podemos executar pequenos SELECT’s em qualquer parte da nossa consulta. Por exemplo:

-- Consulta principal para encontrar pedidos que contenham um item específico
SELECT 
  numero_pedido, 
  data_pedido
FROM pedidos
WHERE numero_pedido IN (
    -- Subconsulta para encontrar os números de pedido que contêm o item específico
    SELECT numero_pedido 
    FROM itens_pedidos
    WHERE nome_item = 'Produto X'
);

Primeiramente obrigado Chat GPT por me dar um exemplo. Segundamente, estamos fazendo uma consulta que retorna todos os pedidos que tiveram um determinado produto. Mas essa consulta poderia ser mais complexa. Imagine que não queremos somente os pedidos, queremos pegar nosso exemplo anterior e juntar também a cidade de onde cliente é:

-- Consulta principal para encontrar pedidos que contenham um item específico
SELECT 
  cidade,
  data_pedido,
  COUNT(numero_pedido) as total_pedidos,
  SUM(receita_pedido) AS total_receita
FROM (
      --Subconsulta para juntar a tabela de pedidos com a de clientes
      SELECT
        numero_pedido,
        data_pedido,
        receita_pedido,
        cidade_cliente
      FROM
        pedidos
        LEFT JOIN clientes USING(cliente_id)
)
WHERE numero_pedido IN (
    -- Subconsulta para encontrar os números de pedido que contêm o item específico
    SELECT numero_pedido 
    FROM itens_pedidos
    WHERE nome_item = 'Produto X'
)
GROUP BY cidade, data_pedido

E acho que podemos ver como a dificuldade de leitura da consulta aumenta junto com a complexidade. Já precisei trabalhar com consultas legadas que tinham mais de 10 níveis de subconsulta atrás de subconsulta, num pesadelo de SELECT * FROM (SELECT * FROM (SELECT * FROM (SELECT * FROM... . Fora as limitações: as subconsultas só podem ser referenciadas uma vez. Se por algum motivo um outro pedaço da sua query precisar de uma subconsulta, você vai precisar repetir.

CTE’s

E é aí que entram as CTE’s, do inglês Common Table Expression,* ou Expressão de Tabela Comum. A CTE é uma construção que permite definir uma tabela temporária dentro da sua consulta. Tem exatamente a mesma ideia que a subconsulta, com a diferença de que a sintaxe fica um pouco mais clara, e de que ela pode ser referenciada várias vezes na sua consulta.

Minha recomendação é usar CTE sempre que possível no lugar de uma subconsulta.

Acho que o jeito mais fácil de explicar é refatorar o exemplo acima, então aqui vai:

WITH pedidos_com_produto AS (
-- Subconsulta para encontrar os números de pedido que contêm o item específico
  SELECT numero_pedido 
  FROM itens_pedidos
  WHERE nome_item = 'Produto X'
),
pedidos_e_cidades AS (
--Subconsulta para juntar a tabela de pedidos com a de clientes
  SELECT
    numero_pedido,
    data_pedido,
    receita_pedido,
    cidade_cliente
  FROM
    pedidos
    LEFT JOIN clientes USING(cliente_id)
)
-- Consulta principal para encontrar pedidos que contenham um item específico
SELECT 
  cidade,
  data_pedido,
  COUNT(numero_pedido) as total_pedidos,
  SUM(receita_pedido) AS total_receita
FROM pedidos_e_cidades
WHERE numero_pedido IN pedidos_com_produto
GROUP BY cidade, data_pedido

Pode ser um grande preconceito meu, mas para mim, essa segunda consulta é muito mais legível. Caso a sintaxe não tenha ficado clara, definimos uma CTE usando:

WITH nome_tabela_temporária AS (
subconsulta
)

Além disso, separamos múltiplas CTE’s por vírgula. E no final, a nossa consulta precisa terminar com um SELECT.

Absolutamente toda consulta com mais de uma etapa que eu escrevo é feita com CTE’s, porque além de separar de forma declarativa as etapas, também ajuda a separar os passos durante a construção da consulta. Se puder deixar uma lição com esse post, é que você tente usar CTE’s caso vá fazer grandes consultas.

Ordem de operações do SELECT

Por padrão, o SQL executa cada cláusula da consulta em uma ordem bem determinada. É interessante entender essa ordem para saber como otimizar consultas, mas isso também nos ajuda a entender como as ferramentas interpretam nosso código.

FROM, incluindo JOINs
WHERE
GROUP BY
HAVING
WINDOW functions
SELECT
DISTINCT
UNION
ORDER BY
LIMIT e OFFSET

Note que o LIMIT é avaliado no final da consulta. Em alguns bancos de dados, isso significa que ele não vai limitar o custo de processamento da sua consulta, apenas o resultado mostrado. Então por via de regra, se você quer economizar em processamento, use o WHERE.

Outras coisas

Além disso tudo ainda existem outros milhares tipos de funções que não trouxe aqui. Podemos lidar com dados geográficos, funções estatísticas, matemáticas, de definição de data, de timestamp e mais um monte de coisas.

Além disso, não mencionei alguns outros assuntos um pouco mais avançados, como funções analíticas e de janelamento, subconsultas correlatas ou até a otimização de queries. Talvez eu faça um outro post sobre SQL avançado, mas não está no cronograma dos próximos meses.

Onde encontrar mais informações

Sinceramente, aprendi SQL na prática muitos anos atrás, fazendo sistemas de CRUD como todo desenvolvedor. Como já mencionei, as próprias documentações das ferramentas tem bons exemplos e explicações da sintaxe das funções, então quando preciso de algo, vou atrás delas.

Também gostei desse material aqui da Data Engineering Wiki, que é um resuminho simples de metade do que falei aqui e mais algumas coisas.

https://dataengineering.wiki/Guides/SQL+Guide

Sei que a Linux Tips fez algumas lives de “SQL Essentials”, que acompanhei brevemente e também recomendo:

https://www.youtube.com/watch?v=_6K_JRLD57E

E caso você queira usar o BigQuery, o Google tem uma documentação muito boa sobre o “GoogleSQL” que define toda a sintaxe, as expressões e as funções. Toda vez que quero fazer algo que não sei fazer no BigQuery, entro na documentação oficial e os exemplos sempre ajudam.

https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax

Vi por cima os materiais da W3Schools e acho que tem bons exemplos e explicações também.

Sobre bancos de dados, o @danielhe4rt tem uma série de 4 partes com alguns conceitos bem interessantes.

Database 101

De forma geral eu aprendi SQL faz muito tempo e não sei boas referências atuais. Se você souber algum bom curso, vídeo, post ou qualquer material manda aí!

E como spoiler, estou há algum tempo planejando um curso completo de SQL, mas com foco em BigQuery. Não tenho nenhuma estimativa, mas com certeza vai sair.

Conclusão

Para mim, o mais importante para saber SQL é entender qual o resultado que você quer, e com base nisso se virar para pesquisar (ou perguntar ao Chat GPT) como você pode fazer.

Uma coisa que faço e que acho boa prática, é que quando vou explicar para alguém como fazer uma determinada tabela, eu construo um exemplo do resultado esperado numa planilha. Como trabalho com modelagem e tratamento de dados, isso também ajuda os analistas a entender como vai ser a tabela que eles vão receber para construir um dashboard ou fazer uma análise, e isso evita retrabalhos caso a nossa consulta não retorne o que precisam.

Também precisa ficar claro que SQL é o tipo de habilidade que você só vai desenvolver praticando. Por mais que você entenda uma consulta feita por alguém, isso não significa que você seria capaz de escrevê-la.

No início a prática consiste em nos acostumarmos com a sintaxe, mas conforme as necessidades vão se tornando mais complexas, ter praticado problemas semelhantes vai te ajudar muito. É difícil falar para uma pessoa iniciante que ela deve pensar por partes e ir desenvolvendo aos poucos, mas essa é a minha principal habilidade na resolução de problemas em geral.

Então minhas dicas são: tente desenhar qual é o resultado final que você quer, escreva de onde vai vir cada dado, e na hora de executar faça uma parte de cada vez, sempre tentando executar partes menores para garantir que está funcionando. Quem sabe a frustração de escrever uma consulta gigante que da erro ou retorna nada vai concordar comigo aqui.

E no geral, entenda bem o custo de executar as coisas na ferramenta que escolher. Mostrei aqui 3 opções gratuitas, mas no contexto de trabalho dificilmente algo será grátis. Por isso fica a recomendação geral de evitar fazer SELECT * por aí.

Me diz o que você achou desse tipo de post, e se você gostaria que isso virasse um vídeo no Youtube! Independente do resultado, pra ajudar a decidir sobre o que será o próximo post me acompanha lá no twitter!

Espero que isso tenha sido útil para alguém, até a próxima!

(Esse foi o primeiro post que publiquei no meu perfil do hashnode! Você pode me acompanhar por lá no blog.cadumagalhaes.dev

Tudo que você precisa saber sobre Terraform

Cadu Magalhães — Tue, 11 Jul 2023 21:06:03 +0000

Terraform é uma ferramenta open source desenvolvida para facilitar a criação, gerenciamento e a automatização da infraestrutura como código (que vamos chamar de IAC, da sigla infra as code). Sua principal vantagem é que você escreve a sua infraestrutura de forma declarativa, e a ferramenta fica responsável por implementar seus recursos de maneira consistente.

A grande maioria de exemplos de utilização de terraform pela internet é com AWS. Como trabalho com Google Cloud, vou fazer os exemplos baseados nisso.

Tudo que eu preciso saber sobre?

Meu objetivo aqui é simples: prover toda informação disponível para você (pessoa desenvolvedora) começar e conseguir usar a ferramenta da vez. Não pretendo responder tudo que você pode ou deveria saber, apenas o necessário.

O que é IAC
O que é Terraform
Quando eu deveria usar Terraform
Por onde começar
- Instalação
- A linguagem do terraform
- Estrutura do repositório
- Terraform settings
- Providers
- Backends
- Terraform state
- Variables
- Declarando valores fixos para as variáveis
- Locals
- Resources
- Modules
- Outputs
- Outras coisas avançadas
Repositório de exemplo
Conclusão

O que é IAC

Antes de seguir e falar especificamente do Terraform, vamos entender um pouco sobre sua base.

Se você que está lendo já formatou um computador pessoal, sabe como pode dar trabalho instalar todos os softwares necessários para fazer alguma tarefa. Agora imagine se o seu trabalho for provisionar computadores para um servidor ou uma aplicação, e que você precisa:

Criar máquinas virtuais
Instalar programas nelas
Criar um banco de dados pra aplicação
Fazer as configurações de rede e firewall

Nesse caso, dependendo da quantidade de vezes que você for fazer isso, faz sentido pensar em automatizar, certo?

Por causa disso, ao longo dos anos surgiram várias ferramentas de automação para facilitar esse tipo de provisionamento. A primeira que eu ouvi falar foi o Ansible, da Red Hat. A ideia é que você escreva arquivos de configuração definindo o que precisa ser criado, e de forma simplificada, qual a ordem das dependências. Isso ajuda a subir infraestruturas de forma consistente.

O que é Terraform

Nas palavras (traduzidas livremente por mim) da Hashicorp, empresa responsável pelo Terraform:

Terraform é uma ferramenta de infaestrutura como código que permite que você construa, mude e versione infraestrutura de forma segura e eficiente.

A ideia é simples: você descreve sua configuração em arquivos, onde você escreve todos os recursos da sua infra (máquinas virtuais, configurações de rede, bancos de dados - virtualmente, qualquer coisa).

O terraform usa a linguagem HCL (Hashicorp Configuration Language) nos seus arquivos, e nele você declara os recursos, que representam os objetos de infraestrutura. Nós chamamos essa linguagem de declarativa, o que significa que vamos escrever o que queremos que seja criado, ao invés de escrever um “passo-a-passo” (um algoritmo) de como as coisas devem ser executadas.

Quando eu deveria usar Terraform

Bom, depende. Minha recomendação é a seguinte:

Toda vez que você for desenvolver um projeto que vai (ou que pode) ser implementado em mais de um lugar, use Terraform. Por exemplo, se você está desenvolvendo uma API ou um serviço, e quer manter separados os ambientes de desenvolvimento e de produção, usar o terraform vai deixar sua vida mais simples.

Se estiver trabalhando num projeto completo que vai ser implantado em nuvem, também recomendo utilizar a ferramenta. Você pode criar funções (cloud functions do GCP ou lambda na AWS), buckets de armazenamento (do GCS ou do S3), automatizar a criação de arquivos de configuração. Ou ainda deixar pré definidas regras de rede, de permissionamento.

Por onde começar

Instalação

Considerando o meu post sobre a configuração do windows para desenvolvimento, vou explicar como instalar apenas em Linux.

Nesse caso, basta acessar a documentação oficial e copiar e colar os comandos. Assim:

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common -y
wget -O- https://apt.releases.hashicorp.com/gpg | \
    gpg --dearmor | \
    sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg
gpg --no-default-keyring \
    --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
    --fingerprint
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
sudo apt update
sudo apt-get install terraform -y
terraform -install-autocomplete

Para verificar a instalação, basta executar o comando terraform -v

A linguagem do terraform

A configuração do Terraform é um documento (ou conjunto de documentos) que diz ao Terraform como gerenciar a coleção da infraestrutura.

A sintaxe da linguagem consiste em alguns elementos básicos:

<TIPO DE BLOCO> "<TIPO/RÓTULO DO RECURSO>" "<RÓTULO DO RECURSO>" {
  # Block body
  <IDENTIFICADOR> = <EXPRESSÃO> # Argument
}

## Exemplo retirado da documentação oficial
## https://developer.hashicorp.com/terraform/language

Eu sei que isso parece um pouco confuso, então a partir de aqui vamos trabalhar com exemplos.

Estrutura do repositório

Antes de realmente falar sobre o terraform, vamos apresentar o repositório que estou trabalhando

assets/
    code.zip
src/
    index.js
    package.json
terraform/
    dev/
        versions.tf
        provider.tf
        backend.tf
        variables.tf
        main.tf
        terraform.tfvars
.gitignore
README.md

Edit: Um ponto MUITO importante que esqueci de comentar. Para o terraform, não importa o nome dos seus arquivos, então essa estrutura é apenas uma sugestão de organização. Muita gente esscreve tudo num único arquivo, eu particularmente prefiro separar em vários. Além disso, normalmente tento fazer nomes que façam sentido com o conteúdo.

Terraform settings

O primeiro passo é definirmos as “dependências” da nossa configuração. Isso porque os recursos, módulos e provedores podem ter versões diferentes.

Eu costumo criar o arquivo versions.tf com esse pedaço de código

terraform {
  required_version = ">= 1.5.2"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 4.73.0"
    }
  }
}

Nesse bloco nós podemos definir

a versão do próprio terraform com a qual nossa configuração funciona (nesse caso, uma versão maior que a 1.5.2)
os provedores que nossa configuração vai usar. No exemplo de hoje, apenas o de google cloud. Mas aqui poderia entrar o provedor de AWS, ou ainda de Kubernetes.

Providers

O passo seguinte - após definirmos as versões que vamos utilizar como base para nossa configuração - é configurar os providers que estamos usando. Esse tipo de configuração vai variar para cada provedor, mas no caso do de Google Cloud, podemos fazer assim: no arquivo provider.tf

provider "google" {
  project = var.project_id
  region  = var.region
  zone    = var.zone
}

Aqui definimos

Qual o projeto do GCP onde as coisas serão criadas
Qual a região padrão dos recursos
Qual a zona padrão dos recursos

Como peguei o exemplo de um projeto real, ao invés dos valores literais nós temos configurações com a palavra var. A ideia é que esse tipo de configuração seja gerenciada em um outro lugar, então vamos deixar assim por hora.

Backends

Honestamente, essa é a configuração mais importante para mim. O objetivo do terraform pode ser automatizar o gerenciamento da infraestrutura, mas por padrão, ele armazena o resultado da configuração no seu computador.

Terraform state

Não mencionei antes porque raramente precisamos nos preocupar com esse arquivo. Como expliquei brevemente acima, o terraform armazena o resultado da sua execução num arquivo, que normalmente fica no seu computador (no mesmo diretório onde está a configuração). Esse arquivo é o state, ou estado. Ele vai ser um registro de toda a infraestrutura atual feita pela sua configuração, contendo todos os recursos que você tem.

Quando você fizer uma alteração na configuração e aplicar novamente, o terraform vai comparar a configuração com o estado para procurar por alterações. E nesse caso, vai mexer somente no que mudou.

Isso é importante porque a configuração do terraform não tem acesso a sua infraestrutura em si, apenas ao que ele gerencia através do estado. Então por exemplo, se eu aplicar uma determinada configuração no meu projeto, e uma outra pessoa do mesmo time tentar aplicar a mesma configuração, com certeza vão acontecer vários erros de “recurso já existente”.

Para mitigar esse tipo de problema, recomendo a utilização dos backends. Com essa função, o estado do terraform é armazenado em um local remoto, e vai ser acessado por todos que tiverem a configuração. Isso também é importante caso sua infra esteja configurada em alguma pipeline de CI/CD.

Agora voltando ao backend, como estamos fazendo um projeto de Google Cloud, vamos usar o Google Cloud Storage (gcs) para armazenar nossos estados. É importante ressaltar que o bucket do storage que vai armazenar o estado já precisa existir, pois o terraform não vai criar por você.

No meu exemplo, vamos criar o arquivo backend.tf

terraform {
  backend "gcs" {
    bucket = "py-project-terraform-states"
    prefix = "example/dev"
  }
}

Esse bloco de backend poderia estar junto das outras configurações de terraform, mas eu costumo manter separado por questão de organização.

Aqui nós definimos:

O id do bucket onde nossos arquivos serão armazenados
O prefixo (na prática a “pasta”) onde os arquivos serão criados. Esse parâmetro é opcional, mas considerando que um projeto pode ter múltiplas configurações de terraform, considero uma boa prática definir o prefixo.

Variables

Todas as etapas anteriores são configurações nas quais você raramente precisará mexer, e por isso gosto de mantê-las em arquivos separados. A partir daqui, vamos lidar com as configurações que vamos escrever enquanto desenvolvemos nosso código.

Começo falando das variáveis justamente porque usamos algumas lá na configuração do *provider*, então geralmente começo com um arquivo [variables.tf](http://variables.tf) com as seguintes configurações:

variable "project_id" {
  description = "Insira o ID do projeto do Google Cloud Platform"
  type        = string
}

variable "region" {
  description = "Insira a região padrão para os recursos do projeto"
  type        = string
  default     = "us-central1"
}

variable "zone" {
  description = "Insira a zona padrão para os recursos do projeto"
  type        = string
  default     = "us-central1-a"
}

A declaração de variáveis é simples.

Nós usamos o bloco variable e definimos o rótulo como sendo o nome da variável. Dentro desse bloco nós podemos passar as configurações

type, que define o tipo da variável. O terraform vai validar se o valor passado bate com esse tipo
description, que vai aparecer num prompt para o usuário na hora da aplicação da configuração
default, o valor padrão da variável, caso o usuário não passe um.

Declarando valores fixos para as variáveis

Quando você tentar aplicar uma configuração de terraform com variáveis, o primeiro passo (após a validação de erros na configuração) é a verificação de variáveis. Por padrão, vai aparecer um prompt interativo para que o usuário preencha as variáveis uma por uma. Como eu tento deixar o máximo possível de configurações dentro das variáveis, esse processo pode ficar trabalhoso. Fora que, caso queiramos automatizar a execução do terraform, esse prompt pode atrapalhar.

Para resolver isso, podemos criar um arquivo terraform.tfvars. O terraform vai buscar no arquivo de extensão .tfvars os valores para as variáveis declaradas. Então para as variáveis de exemplo acima, podemos ter um arquivo assim:

project_id = "cadumagalhaes-terraform-example"

E dessa forma, ao executar a nossa configuração, o id do projeto já será conhecido.

Locals

Além das variáveis declaradas como variables, podemos criar variáveis temporárias usando o bloco locals. Esse tipo de configuração é interessante para os casos em que você não quer que o usuário que vai executar a configuração possa alterar seus valores (pelo menos sem alterar a configuração em si). Eu costumo usar para valores estáticos que posso usar múltiplas vezes, como o nome de uma imagem docker. Para o exemplo de hoje, vamos armazenar o caminho da raiz do nosso repositório (isso vai ser utilizado mais tarde).

Para o caso desse tipo de configuração, não costumo colocar em arquivos separados. Hoje vamos criar todas as próximas configurações dentro do arquivo main.tf

locals {
  root_dir   = abspath("../../")
}

Aqui podemos declarar quaisquer variáveis com valores fixos para usar dentro da nossa configuração.

Resources

Agora a parte mais importante, que é descobrir como vamos realmente criar os recursos que precisamos no nosso projeto. Aqui a receita é simples:

Decidir o que precisa ser criado
Pesquisar no google terraform [recurso que você quer]
Entrar na documentação oficial do terraform.

Por exemplo, para criar uma google cloud function:

Nesse caso, o primeiro link é a página do módulo completo de Cloud Functions, com uma documentação mais “bonitinha” e formatada. Eu costumo entrar no segundo link, que é o do recurso, porque ele já vem com vários exemplos de implementação e links das documentações do google.

Aqui nós podemos ver que a sugestão da documentação é que nós criemos mais um bucket do cloud storage, em seguida nós fazemos upload do nosso código fonte para esse bucket, e por último criamos a cloud function.

No nosso caso, o arquivo [main.tf](http://main.tf) ficou assim

locals {
  root_dir = abspath("../../")
}

resource "google_storage_bucket" "bucket" {
  name     = "test-bucket"
  location = var.region
}

resource "google_storage_bucket_object" "archive" {
  name   = "code.zip"
  bucket = google_storage_bucket.bucket.name
  source = "${local.root_dir}/assets/code.zip"
}

resource "google_cloudfunctions_function" "function" {
  name        = "function-test"
  description = "My function"
  runtime     = "nodejs18"

  available_memory_mb   = 128
  source_archive_bucket = google_storage_bucket.bucket.name
  source_archive_object = google_storage_bucket_object.archive.name
  trigger_http          = true
  entry_point           = "helloGET"
}

Modules

Isso é um assunto pra outro dia, pois não acho que sejam necessários para começar a usar Terraform. Um módulo é quando você encapsula um conjunto de recursos e configurações que podem ser reutilizados apenas trocando suas variáveis. Por exemplo, no caso acima nós poderiamos ter criado um módulo que cria uma Cloud Function, e ao invés de declarar os 3 recursos (bucket, arquivo e function) declarar somente o módulo.

Outputs

Os outputs são como variáveis que são criadas pela nossa configuração, e que queremos expor de alguma forma. Num módulo o output poderia ser o nome do recurso, por exemplo. Aqui no nosso exemplo, como temos uma Cloud Function que é acionada por HTTP, podemos definir como output o endereço dela. No final do main.tf

output "function_url" {
  value = google_cloudfunctions_function.function.https_trigger_url
}

Dessa forma, quando a configuração terminar de ser executada, teremos o link da Cloud Function no nosso terminal.

Outras coisas avançadas

O Terraform tem várias funções prontas (para gerar um valor aleatório, por exemplo), expressões condicionais, de repetição, criação de templates de string. Apesar de ser uma linguagem declarativa, podemos criar configurações bem poderosas e resilientes usando esse tipo de feature.

Repositório de exemplo

O código completo com o exemplo está no meu github:

1cadumagalhaes/terraform-gcf-nodejs-example

Vale ressaltar que essa Cloud Function precisa de autenticação para ser executada. Para testar, você pode executar o comando abaixo no seu terminal

curl  -H "Authorization: bearer $(gcloud auth print-identity-token)" \
  [FUNCTION_URL]

Isso vai gerar o token necessário para autenticação e fazer a chamada HTTP usando o curl.

Conclusão

Comecei a trabalhar com Terraform no inicio do ano passado, não sabia absolutamente nada e sinceramente nós apanhamos um pouco pra deixar a configuração pronta. O conteúdo que coloquei aqui é basicamente o que eu precisei para conseguir usar de forma confortável em projetos novos e ter 0 dor de cabeça. Confesso que não usei muitos conteúdos não oficiais sobre o assunto, então se tiver alguma recomendação, deixa aqui em baixo!
Como sempre, tem um video muito bom disso lá no canal da LINUXtips

Descomplicando o Terraform | HashiWeek

Espero que isso tenha sido útil para alguém, até a próxima!

Tudo que você precisa saber pra usar Docker

Cadu Magalhães — Tue, 13 Jun 2023 14:48:53 +0000

De forma muito simplificada, Docker (a plataforma*) é um software open source que foi feito com o objetivo de facilitar o processo de desenvolver, implantar e executar aplicações. Em resumo, é uma plataforma de virtualização através de contêineres.
Outra forma de resumir é dizer que é um dos softwares que tem o objetivo de evitar o clichê do

Na minha máquina funciona.

* Docker pode ser o projeto, a ferramenta/plataforma, a empresa. Aqui vamos falar sobre a ferramenta

Vou deixar alguns exemplos específicos de Node e Python, mas no geral esse post é feito para quem já sabe desenvolver ou já tem uma aplicação pronta, e quer colocar ela para rodar em contêineres.

Se você for iniciante, talvez alguns pedaços não façam muito sentido. Nesse caso pode deixar um comentário que eu tento explicar da melhor forma possível.

Tudo que eu preciso saber sobre?

O que é Docker

Docker é uma plataforma de virtualização por contêiner, que permite empacotar e executar aplicativos de forma isolada do sistema operacional.

Pra complementar, vou deixar um subtópico aqui:

O que são contêineres

Contêineres (ou containers) são uma forma de virtualização de computadores que usa recursos do sistema operacional (SO) hospedeiro, ao invés de precisar fornecer um SO inteiro - como seria uma máquina virtual (VM) - para executar o que precisar. O contêiner compartilha o kernel do SO, e por isso é muito rápido para iniciar e interromper, e altamente portátil. Sua principal vantagem é permitir a execução de aplicações em um ambiente isolado, o que garante que a sua execução em qualquer máquina será a mesma.

Quando eu deveria usar Docker

Desde que eu aprendi a usar, a minha resposta é sempre. Existem alguns aspectos que podem fazer a sua utilização parecer um empecilho, principalmente durante o desenvolvimento, mas vou tentar desmistificar tudo isso e te ajudar a usar da forma mais simples que conheço.

Mas respondendo de forma mais completa, os principais motivos para usar contêineres (na minha opinião) são:

1. Fazer uma aplicação com objetivo de publicar

Para resolver uma lista de exercícios de lógica de programação da faculdade usando contêineres, seria um pouco de exagero (mas é possível).

Mas toda vez que você estiver trabalhando em uma aplicação - um site, ou uma api por exemplo - que eventualmente vai ser publicada de alguma forma, encapsular em contêineres vai facilitar muito a sua vida na hora de fazer a implantação (ou deploy).

Isso porque o isolamento garante que todas as dependências utilizadas - e aqui podemos considerar pacotes (do npm ou do pip, por exemplo), programas disponíveis no sistema operacional ou até arquivos - estarão disponíveis quando chegar a hora da implantação.

2. Padronizar o ambiente de desenvolvimento

O motivo é o mesmo acima, basicamente. Caso você trabalhe em mais de um computador (eu uso o meu notebook pessoal com linux e o notebook da empresa com windows, por exemplo), ou simplesmente esteja desenvolvendo algo em equipe, conteinerizar a sua aplicação vai facilitar muito a configuração inicial do ambiente para começar a desenvolver sem gastar horas instalando programas e pacotes específicos.

Por onde começar

Instalação

No meu post sobre a configuração do windows para desenvolvimento eu já expliquei como se instala no Windows, por isso não vou repetir aqui (o link já está com a âncora do pedaço sobre Docker).

No caso de Linux, para instalar basta executar os comandos abaixo:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Isso vai baixar o script de instalação oficial do docker e em seguida executar. Esse script não funciona para instalação no WSL, pois o script identifica que estamos no Windows e recomenda que você instale usando o Docker Desktop.

Dica: caso queira instalar em algum servidor de forma automática (com terraform, por exemplo), você pode executar o segundo comando como mostrado abaixo. Isso vai garantir que não fique parado no prompt de confirmação

yes | sudo sh get-docker.sh

Dockerfile

A base de conteinerizar aplicações está na construção do Dockerfile. Esse arquivo pode ser bem complexo, mas o que você precisa saber é:

FROM

Logo no inicio do seu arquivo, o primeiro comando precisa ser o FROM. Ele é o ponto de partida da sua imagem, e define qual é a base do seu container.

Uso:

FROM <image>
FROM <image>:<tag>

Por exemplo, se eu usar

FROM python:3.11

Vou ter uma imagem que já vai vir com python instalado, além de uma série de dependências comuns de aplicações em python.

De forma semelhante, poderia usar FROM node:20.3-slim para inicializar uma aplicação em Node JS.

O seu Dockerfile pode ter vários comandos FROM, juntando pedaços de imagens diferentes para montar a sua aplicação.

Uma coisa que você precisa se atentar, é que as imagens* utilizadas vão ter tamanhos diferentes, dependendo da quantidade de coisas que tem instaladas. Imagens mais completas são mais pesadas, e a maioria das imagens comuns tem uma versão -slim , que geralmente vai ter menos dependências.

De forma geral, se você estiver preocupado com o tamanho da imagem do seu container, o ideal seria começar com uma imagem mais “limpa” e instalar manualmente todas as ferramentas que vai utilizar. Mas normalmente não precisamos nos preocupar com isso, então usar a imagem -slim já é um bom começo.

COPY

O próximo passo - considerando que a imagem que escolhemos já tem os programas que precisamos - é passar os arquivos com o seu código para ela, para que possam ser executados. Podemos fazer isso usando o comando ADD, ou o comando COPY. O primeiro é basicamente o segundo com esteróides, pois além de permitir a cópia, também permite o download de arquivos remotos (através de uma URL) e a descompressão de arquivos comprimidos.

Uso:

COPY arquivo
COPY [arquivo_fonte.py](http://arquivo.py) arquivo_destino.py
COPY pasta_fonte/ pasta_destino/

Isso vai definir onde os seus arquivos vão ser copiados dentro da imagem do contêiner, e é necessário para que possamos executar. Um exemplo comum, no caso de uma aplicação em python por exemplo, é copiar o requirements.txt além da pasta com o seu código (no meu exemplo, app/

COPY requirements.txt
COPY app

Voltando para o Node, vou aproveitar e apresentar o .dockerignore. Semelhante ao .gitignore, a função dele é definir no seu projeto (ou pasta) quais arquivos ou diretórios não devem ser acrescentados na imagem. Node é um bom exemplo porque quando instalamos as dependências do nosso projeto (de um package.json, por exemplo), elas são salvas na pasta node_modules/, dentro do diretório em que estivermos. Essa pasta pode ser muito grande, por isso podemos criar o arquivo .dockerignore contendo ela:

node_modules/

E depois, quando fizermos a cópia, saberemos que essa pasta não estará na nossa imagem

COPY meu_projeto_node

RUN

Em seguida, dependendo da sua aplicação vai ser necessário instalar as dependências do seu projeto para conseguir executar (por isso copiamos o requirements.txt, por exemplo). Para isso usamos o comando RUN, que serve para executar qualquer comando de script dentro da sua imagem. Você pode ter múltiplos comandos RUN, e eles vão ser executados no momento da criação da sua imagem.

Uso:

RUN comando
RUN comando complemento
RUN ["comando", "complemento"]

Para instalar as dependências de um projeto de python por exemplo, podemos colocar o seguinte após o nosso COPY

RUN pip install -r requirements.txt

Esse comando também pode ser utilizado para instalar pacotes no seu sistema (com apt install por exemplo) ou executar qualquer comando de shell.

CMD

Por fim, também podemos configurar comandos que devem ser executados quando o container for executado. É aqui que dizemos como a nossa aplicação deve ser executada, por exemplo.

Uso:

CMD comando
CMD comando complemento
CMD ["comando", "complemento"]

Numa aplicação python simples por exemplo, podemos executar algo como

CMD python app.py

Ou numa aplicação em Node, podemos executar

CMD npm start

Um ponto importante sobre o CMD, é que somente o último comando inserido no seu Dockerfile vai ser executado. Por exemplo, se tivermos

CMD python main.py
CMD python app.py

Somente o segundo será executado.

Caso sua aplicação precise executar mais de um comando para ser inicializada, podemos usar o comando ENTRYPOINT, que funciona de forma semelhante.

Comandos docker

build

Dentro da pasta da sua aplicação onde você criar o seu arquivo Dockerfile (normalmente são colocados na raiz do projeto, mas vai depender da sua organização), você deve executar o comando

docker build [PATH]

Caso não passe nenhum PATH, ele procurará o Dockerfile no diretório atual. Se estiver em outra pasta, basta passar o seu caminho (algo como docker build container/

run

Esse é o comando principal para utilização de docker, e não vou entrar em muitos detalhes, mas a sintaxe básica é:

docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

As opções mais comuns que eu costumo utilizar são:

—name: vai definir o nome do seu container. Se não for passado, vai criar com um nome aleatório
--volume, ou -v: permite conectar um diretório local com um diretório do container
--expose, ou -p: permite expor e mapear portas do seu container para o seu sistema local. Isso é muito importante caso esteja desenvolvendo serviços web
-e: permite passar variáveis de ambiente para o contexto do seu container

Acessando o seu container

Apesar de ser mais um comando, gosto de separar este pois permite que tenhamos acesso ao exato contexto do nosso container.

docker exec -it [container] bash

Executando esse comando, entraremos num shell interativo do nosso container e que nos permite acessar como qualquer terminal Linux. Dentro deles podemos navegar entre os arquivos, editar e executar comandos. Isso pode ser muito útil caso precise debugar algum problema, mas o caso de uso mais comum para mim foi fazer a manutenção de containeres baseados em imagens prontas, para criar um usuário de uma aplicação por exemplo (dentro do container de Airflow).

Publicando a sua imagem

Esse tópico sozinho poderia ser um post a parte, por isso vou tentar resumir.

Depois de construir a nossa imagem, nós podemos disponibilizar ela em algum repositório de imagens. Isso facilita a implantação, pois a partir do momento em que a imagem está construida, você não precisa mais dos arquivos do código fonte para executar. Existem vários repositórios, mas minhas recomendações são:

Registros públicos

Docker Registry: o repositório oficial permite que você poste suas imagens e deixe acessíveis para qualquer pessoa
Github Container registry: também é possível armazenar suas imagens no Github

Registros privados

Docker hub: A Docker Inc (a empresa, não o produto) também oferece um serviço de hospedagem privado para salvar suas imagens
Qualquer nuvem, mas como exemplo vou destacar o Artifact Registry do Google Cloud

Dessa forma, quando for executar o seu serviço, basta referenciar o endereço remoto da imagem na hora da execução. Por exemplo:

docker run ghcr.io/1cadumagalhaes/TESTE_DOCKER:latest

Isso significa que, caso eu queira fazer o deploy da minha aplicação numa VM hospedada em alguma nuvem por exemplo, tudo que eu preciso fazer é:

Instalar o Docker
Executar esse comando referenciando a minha imagem já existente

Sem se preocupar em clonar o código e sem nenhum setup.

Docker Compose

O Compose é uma ferramenta desenvolvida pra definir e executar aplicações que dependem de múltiplos contêineres docker. Com ele, você usa um arquivo de configuração YAML para definir os serviços da sua aplicação, e depois executa tudo com um único comando.

Apesar de ser focado em aplicações com múltiplos contêineres, eu considero muito prático usar para definir aplicações de um único contêiner também. Isso porque ele permite que nós façamos as definições do nosso serviço de forma declarativa. Por exemplo, digamos que eu esteja trabalhando no desenvolvimento de uma API feita em Python e que vai criar arquivos dentro do sistema, e que usa algumas configurações passadas via variável de ambiente. Para executar o meu container, eu precisaria fazer o seguinte comando:

docker run \
-v ./output:/app/output \
-p 8080:8080 \
-e NAMESPACE='staging' \
-e LOG_LEVEL='debug' \
-e API_KEY='abc123' \
--name meu_python \
.

Claro que podemos salvar tudo isso num shell script (ou simplesmente decorar o comando), mas eu considero inconveniente. Ao invés disso, podemos definir um docker-compose.yaml assim:

services:
  meu_app:
    buid: .
    ports:
      - "8080:8080"
    environment:
      - NAMESPACE: 'staging'
      - LOG_LEVEL: 'debug'
      - API_KEY: 'abc123'
    volumes:
      - ./output:/app/output

E depois de configurar esse arquivo, podemos executar nossa configuração com

docker compose up

Também podemos usar os comandos down e restart além do up, e podemos passar várias opções, como:

-f : Caso o nome do seu arquivo seja diferente de docker-compose.yaml , podemos passar através dessa opção
-d : para executar os contêineres “desacoplados”, ou seja sem depender da sua sessão do terminal e ficar em background.

Usando Hot Reload com Docker

Muitas vezes, quando estamos desenvolvendo precisamos da agilidade de reiniciar o serviço assim que salvamos nossas alterações.

No ambiente local existem ferramentas próprias para isso, como o nodemon de Node JS, e elas podem auxiliar muito para que vejamos os resultados das nossas alterações.

Por padrão, para alterar códigos dentro do seu contêiner, você precisa alterar a sua imagem. E para isso, é necessário compilar a imagem (docker build) e executar novamente (docker run).

Caso você queira usar uma ferramenta de hot/live reload, você pode definir um volume conectando o seu diretório local com o diretório do contêiner, e dessa forma as alterações estarão conectadas. Por exemplo, caso esteja construindo uma API em Python (com FastAPI por ex) e executando com Gunicorn, podemos fazer o seguinte:

No Dockerfile

FROM tiangolo/uvicorn-gunicorn-fastapi:python3.11
COPY requirements.txt /usr/src/requirements.txt
RUN pip install -r /usr/src/requirements.txt
COPY ./app /app/app

No docker-compose.yaml

services:
    api:
        build: .
        ports:
           - '8080:80'
        volumes:
           - ./app/:/app/app
        command:
           - /start-reload.sh

Dessa forma, quando fizermos qualquer alteração no nosso código, o serviço será reiniciado dentro do contêiner. Caso queira fazer o mesmo com Node, esse post do Erick Wendel no freeCodeCamp explica como fazer essa configuração.

Onde encontrar mais informações

Além das documentações oficiais, a principal referência que eu tenho é o treinamento da LINUXtips, feito pelo Jeferson Fernando. Ele disponibilizou completamente de graça o livro Descomplicando o Docker depois de dar o treinamento de graça pra 5 mil pessoas (incluindo eu, na época um jovem padawan estagiário):

https://livro.descomplicandodocker.com.br/

E depois ele resolveu liberar o treinamento todo completamente de graça no youtube.

Playlist Descomplicando o Docker no LINUXtips

Esse treinamento é MUITO completo e tem toda informação que você vai querer saber, então vamos combinar de ir lá no canal dele e deixar a Inscrição e deixar o like nos videos?

Conclusão

Coloquei aqui tudo que eu precisei pra conseguir trabalhar com docker nos últimos meses, do desenvolvimento do 0 até o deploy do serviço em produção. Essa é uma ferramenta muito poderosa e que tem muitos detalhes que eu não cobri aqui, por isso reforço que de uma moral para os materiais da LINUXtips.

Se você não sabia nada sobre docker e não conseguiu usar depois desse guia, me procura no twitter pra gente tentar deixar esse post mais completo.

E caso esse post tenha te ajudado de alguma forma, compartilha com alguém que você acha que também pode aproveitar.

Me diz o que você achou desse tipo de post, e se você gostaria que isso virasse um vídeo no Youtube! Independente do resultado, o post ~~da semana que vem~~ dessa semana será sobre Terraform. Me acompanha no twitter pra saber mais!

Espero que isso tenha sido útil para alguém, até a próxima!

Tudo que você precisa saber pra usar Linux

Cadu Magalhães — Sat, 03 Jun 2023 00:07:26 +0000

Linux é meu sistema operacional principal desde 2019. Complementando o post da semana passada sobre WSL, decidi começar essa série de posts ensinando tudo que você precisa saber para conseguir usar Linux, mesmo que dentro do WSL.

Tudo que eu preciso saber sobre?

O que é Linux

De forma geral, Linux é usado pra descrever os sistemas operacionais que são baseados no Kernel Linux, mas não vamos entrar em detalhe aqui. Podemos considerar como um tipo ou conjunto de sistemas operacionais, cujo princípio está no kernel que é de código aberto. Por isso, toda distribuição Linux também é de código aberto.

Quando eu deveria usar Linux?

Minha resposta pessoal é que todos deveriam testar sistemas operacionais diferentes, mas isso fica pra um post a parte. Quando pergunto para usuários de Linux o motivo de escolherem esses sistemas, as respostas são:

1. O sistema é Open Source

O fato de ser de código aberto significa que a comunidade pode contribuir ativamente com o desenvolvimento, resolver bugs, encontrar falhas, e principalmente estender o sistema para as próprias necessidades.

2. Personalização

Vou mencionar brevemente mais tarde, mas existem milhares de sistemas diferentes baseados em Linux. Os sistemas podem ter diferenças na arquitetura, no sistema de arquivos, no gerenciamento de pacotes, no tipo de interface gráfica, na disposição dos elementos da UI, nos softwares que já vem instalados.

O ecossistema Linux é tão rico porque os usuários (e desenvolvedores) não satisfeitos com a forma como usam seus computadores resolvem fazer as alterações que melhoram suas experiências.

3. A comunidade (e seus softwares e suporte)

A comunidade Linux é incrivelmente ativa. Acho que muito por necessidade, visto que por muito tempo a utilização do sistema era somente para usuários avançados (seja para personalização, por compatibilidade de software, para resolver bugs). Você pode procurar como resolver algum problema, como instalar algum programa, como fazer escrever um script, resolver algo usando a linha de comando e na maioria das vezes vai encontrar não só uma resposta, mas uma discussão e uma explicação de como funciona e onde você pode achar mais detalhes.

E graças a comunidade, muitos dos problemas comuns acabam virando um pacote (basicamente um programa), que na maioria das vezes é distribuido gratuitamente, e tem seu código aberto. Mesmo quando as marcas (logitech por exemplo, mas a lista é imensa) escolhem não oferecer suporte dos seus dispositivos - ou dos softwares que vem com eles - para Linux, existem grandes chances de você encontrar uma opção (para dispositivos sem fio da logitech por exemplo, deixo a recomendação do Solaar, que não só é um software mais leve que o oficial, mas que oferece a maioria das opções disponíveis e ainda tem um ícone na barra de tarefas com a carga da bateria, e manda notificações quando está acabando)

4. Segurança

Devido ao design, e (novamente) pela comunidade, Linux é considerado simplesmente mais seguro que Windows. A quantidade de usuários monitorando, identificando e resolvendo vulnerabilidades faz com que os problemas sejam resolvidos muito rapidamente, além de ter um sistema de controle de acesso muito robusto. O fato de ter uma base de usuários menor que windows também significa que vai ser um alvo menos procurado para ataques como vírus ou malwares, que normalmente vão ser desenvolvidos para funcionar em Windows (apesar disso, não significa que você estará livre de preocupações de segurança).

5. Performance

Linux precisa de pouquíssimos recursos para funcionar, de forma que existem distribuições focadas em economizar recursos. O Ubuntu Mate por exemplo, roda em computadores com 1GB de memória RAM, 10GB de espaço em disco e um processador de 1GHz, isso contando com uma interface completa e sem nenhum “corte” de funcionalidade. Pesquisando na internet você vai encontrar vários exemplos de como pessoas “revitalizaram” seus computadores antigos instalando algum Linux neles.

6. Utilização em servidores

Linux é o sistema mais utilizado para servidores, basicamente pelos motivos citados acima.

Por onde começar?

Bom, se você é desenvolvedor, um bom começo é o WSL, que já expliquei como configurar na semana passada. Dentro do WSL você vai ter um terminal (que é basicamente o que teria acesso num servidor), e apesar de usuários comuns não precisarem abrir a linha de comando para nada (dependendo do sistema que estiverem usando), conhecer as ferramentas de linha de comando pode ser bem importante.

Se você quer somente testar, você pode escolher qualquer distribuição Linux, criar um USB bootável com uma instalação do sistema e começar a usar. Isso não vai mexer com a instalação do seu windows e não vai alterar nenhum arquivo no seu sistema, de forma que você pode fazer isso em praticamente qualquer computador.

Minha recomendação é começar com qualquer variação de Ubuntu, que por ser o sistema mais utilizado é o que tem a maior comunidade e suporte. Eu particularmente uso o PopOS, mas você pode pesquisar por “ubuntu flavours” e escolher o que achar mais bonito. Se quiser uma experiência mais próxima do que se tem com o Windows, o Zorin OS pode ser uma boa escolha.

Linha de comando

Bom, eu aprendi os comandos conforme a necessidade, então é complicado levantar exatamente o que você vai precisar usar. Vou copiar o conteúdo de uma palestra que dei uma vez sobre dicas de Terminal, e que serviu de inspiração para o post 3 dicas de terminal para Engenheiros de Dados no blog da DP6

Comandos que você precisa saber

Abaixo estão os comandos mais essenciais para utilização do sistema. Com eles você aprende a navegar entre pastas e a fazer todo o gerenciamento básico de arquivos. Como bônus, a maioria desses comandos são bem semânticos, então coloquei a explicação em inglês do seus significados para os que sei.

# Comandos que você precisa saber:

ls [path] -a -l -h -R # listing, lista os arquivos e diretórios. -a ou –all lista inclusive ocultos, -l informações extras e -h formata de forma legível (human readable)
cd [path] # change directory, serve para navegar entre as pastas. Para voltar uma pasta, use ..
cp [path ou file] [dest] -r # copy, copia o arquivo ou pasta para o destino. -r significa recursivo
mv [path ou file] [dest] -r # move, move o arquivo ou pasta para o destino. Pode ser usado para renomear
rm [path ou file] [dest] -r -f # remove, apaga arquivos ou diretórios
mkdir [path] # make directory, cria pastas
rmdir [path] -r # remove directory, apaga pastas
touch [file] # cria um arquivo vazio com nome informado no parâmetro [file]
nano [file] # editor de texto, sabia mais em https://www.vivaolinux.com.br/artigo/Introducao-ao-Linux-O-editor-de-texto-Nano
vi [file] # editor de texto, https://www.vivaolinux.com.br/artigo/Guia-rapido-VI
sudo [comando] # super user do, usado para executar o comando com permissão elevada
clear # limpa a interface do terminal

Comandos úteis

Aqui alguns comandos para aplicações mais específicas, como ver parte do conteúdo de um arquivo, pesquisar um arquivo dentro de uma pasta, alterar o conteúdo em batch, verificar o que está rodando no seu computador, baixar arquivos, gerenciar permissões e etc

head [file] -n=[num] # imprime as 10 primeiras linhas do arquivo, ou as [num] linhas
tail [file] -n=[num] # imprime as 10 últimas linhas do arquivo, ou as [num] linhas'
find # procurar por arquivos e diretórios
grep # procura um padrão (de texto ou regex) no arquivo ou na string
sed # stream editor, pode fazer transformações de texto no arquivo ou string
awk # procura um padrão (de texto ou regex) no arquivo ou na string, mas usa uma linguagem de processamento
top # lista os processos sendo executados no pc
env # lista ou cria variáveis de ambiente na seção do terminal
chmod # muda o acesso ou permissão do arquivo, ou diretório
chown # muda o proprietário do arquivo ou diretório
wget [options] [url] # Realiza requisições HTTP para a URL informada, para uma requisição simples não é necessário passar nenhum parâmetro adicional a URL, o comando possui vários parâmetros complementares

O mais importante

Nunca - sério, nunca - saia copiando comandos de fontes não oficiais sem entender exatamente o que está fazendo. Mesmo em tutoriais oficiais de instalação de ferramentas, leia os comandos antes de copiar e executar no seu computador. A linha de comando é uma ferramenta muito poderosa, e a partir do momento em que você da permissão (ao executar algo com sudo, por ex), qualquer alteração pode ser feita.

Se não souber o que um comando faz, você pode usar o site https://explainshell.com/, que explica todos os pedaços de um comando.

Além disso, sempre leia o que está escrito no terminal antes de confirmar qualquer coisa. Eu sempre gosto de dar o exemplo do vídeo Linux HATES ME do canal Linus Tech Tips, onde ele tentou fazer um desafio de usar Linux por 30 dias. Nos primeiros minutos de utilização ele tentou instalar a Steam, e quando não conseguiu recorreu a linha de comando. O terminal explicou que ele estava fazendo algo que iria danificar o sistema e pediu para ele digitar uma frase inteira como confirmação, e ainda assim ele confirmou. Depois disso o sistema não abriu mais. (basicamente ele tentou a instalação num dia em que a Valve subiu um pacote corrompido de instalação da steam, e o sistema tentou fazer de tudo pra que ele não instalasse)
Se estivesse usando windows e não conseguisse instalar a steam, ele provavelmente não abriria o powershell pra tentar resolver.

Perguntas frequentes

Linux ou Windows?

Depende. Sistema Operacional é uma escolha pessoal, então você deve usar o que atende as suas necessidades. Mas eu defendo que as pessoas usam Windows porque é a opção que foram apresentadas, e não porque ele atende as necessidades. É bizarro esperar que todas as pessoas do mundo vão usar o computador da mesma forma, então realmente acho que todos deveriam testar vários sistemas diferentes. Da mesma forma, a maioria das interfaces de Linux são feitas para utilizar de formas bem diferentes do windows. Além disso, Android é Linux e serve de exemplo disso. O Android de cada marca é diferente. Sejam detalhes na interface, a forma de utilizar, o menu de notificações. E hoje já é natural as pessoas preferirem uns a outros.

Qual a melhor distro Linux?

Depende. Novamente, é uma escolha pessoal. Como mencionei antes, recomendo Ubuntu pela comunidade e suporte, e uso o PopOS porque me adaptei bem a interface e sou muito mais produtivo do que com Windows.

Eu consigo fazer no Linux tudo que faço no Windows?

Resposta curta: não. Resposta certa: sim, se você (ou alguém) desenvolver algo. Como já falei, a maioria das marcas não oferece software com suporte a Linux, por exemplo. Alguns jogos como Valorant tem seu anticheat baseado no kernel de Windows, então é impossível executar no Linux. Alguns outros, como o Fortnite simplesmente escolhem não dar suporte. Caso você se interesse por jogar no Linux, o Proton DB tem o status de todos os jogos na steam, se as pessoas conseguiram jogar e como.

Onde encontrar mais informações

Eu aprendi principalmente com 2 canais:

Todos brasileiros e com muito conteúdo de qualidade. O guia foca deve ser responsável pelo conhecimento de linux de pelo menos metade dos usuários brasileiros das últimas decadas (fonte: vozes da minha cabeça). O diolinux também tem vários cursos disponíveis para membros do canal, e o LinuxTIPS tem o Treinamento Linux Essentials (além de alguns mais avançados), que é sensacional. Fora isso aprendi em issues do github, perguntas do stackoverflow e posts de comunidade por ai.

Se você tiver alguma recomendação de criador de conteúdo que fale sobre Linux, deixa o comentário aqui!

Conclusão

A verdade é que você não precisa saber muito para conseguir usar Linux. Eu comecei basicamente escolhendo uma distro, instalando e usando. Conforme encontrei barreiras, fui aprendendo mais coisas, mas na maioria das vezes você vai ter uma experiência bem satisfatória sem ter que se preocupar muito.

Me diz o que você achou desse tipo de post, e se você gostaria que isso virasse um vídeo no Youtube! Independente do resultado, o post da semana que vem será sobre Docker. Me acompanha no twitter pra saber mais.

Espero que isso tenha sido útil para alguém, até a próxima!

Configuração do Windows para desenvolvimento

Cadu Magalhães — Fri, 26 May 2023 19:01:15 +0000

Atualizando um post de alguns anos atrás

No ano passado eu convenci as pessoas do trabalho de que o WSL deveria ser padrão para os Engenheiros de Dados da empresa, para conseguir agilizar o desenvolvimento de soluções (muito porque os computadores vem com windows e da trabalho fazer o setup de linux), mas também porque acredito que é a melhor forma de desenvolver ~~para quem não quer usar linux~~.

Então resolvi atualizar esse post para servir de referencia para os meus colegas, mas também pra qualquer pessoa que queira fazer esse setup.

O que é WSL e por que eu deveria usar isso?

Se você pesquisar essa sigla no google, vai descobrir que é assim que chamam a Liga Mundial de Surf (World Surf League, em inglês).

Mas, no nosso contexto, WSL significa Windows Subsystem for Linux , e foi a forma que a Microsoft encontrou de permitir que os usuários - principalmente desenvolvedores - pudessem executar um ambiente Linux (incluindo ferramentas de linha de comando, principalmente) diretamente no windows, sem modificar o sistema e sem a necessidade de criar uma máquina virtual.

O WSL foi lançado oficialmente em 2016, mas era apenas uma ~~gambiarra~~ camada de compatibilidade. Em 2019, a Microsoft anunciou o WSL 2, introduzindo algumas mudanças importantes como a utilização de um kernel de Linux, o que faz com que ele seja compatível com mais programas de linux.

Curiosamente, comecei a usar Linux em 2016, e testo o WSL desde o lançamento dentro do Windows Insider.

Existem alguns motivos pelos quais você deveria dar uma chance ao Linux para desenvolver, mas eu vou destacar somente alguns:

Disponibilidade de ferramentas: a maioria das bibliotecas de desenvolvimento são construídas para rodar em GNU. Um bom exemplo é o Docker, que para funcionar em windows usa o WSL como backend
Facilidade de instalação/manutenção de ferramentas

E considerando apenas o WSL, podemos acrescentar

A instalação e execução das coisas fica separada do seu sistema
Você não precisa de permissão de administrador para instalar ferramentas de desenvolvimento ou configurar variáveis de ambiente

Requisitos

Estou utilizando:

Windows 11 Pro versão 22H2 (necessário Windows 10 versão 2004 ou maior)
VS Code como editor
Extensão do WSL para o VS Code
Windows Terminal

Configuração do WSL 2

A partir daqui, estarei seguindo o tutorial da microsoft, e anotar como resolvo qualquer problema que encontrar.

A última vez que escrevi esse tutorial, eram necessários uns 3 ou 4 comandos. Para as versões mais recentes do Windows, isso é feito com um comando.

1. Abrir o PowerShell ou o Prompt de Comando como administrador.

Dica: você pode apertar Win + X para abrir o menu de contexto do Iniciar, e nele deve ter uma opção de executar o PowerShell como administrador.

2. Executar o comando

wsl --install

3. Reinicie o computador

4. Escolher uma distro Linux (opcional)

Por padrão, ele vai instalar o Ubuntu, que vem na versão 22.04 LTS. Quando iniciar o computador, ele vai finalizar a instalação, e vai te pedir algumas configurações.

Para escolher outra distro, você pode ver as disponíveis com o comando

wsl -l -o

Para instalar o Ubuntu 22.04, por exemplo:

wsl --install -d Ubuntu-22.04

5. Configurar seu usuário e senha

Quando finalizar a instalação, ele vai pedir que você configure o seu UNIX username e a sua senha. Esse usuário será o padrão da instalação, e a senha será a que você precisa utilizar quando rodar comandos com sudo

6. Atualização de programas

Como estamos instalando uma versão com pouco mais de 1 ano de lançamento, é importante atualizar todos os pacotes. Dentre as atualizações, estão algumas atualizações de segurança do kernel Linux.

sudo apt update && sudo apt upgrade -y

Além disso, uma vez por dia o WSL mostra a seguinte mensagem:

Para desabilitar, basta criar o arquivo .hushlogin na home do usuário:

touch ~/.hushlogin

Configuração do Windows Terminal

O Windows Terminal é um aplicativo de terminal bem satisfatório. Ele permite abrir várias abas, mesmo de tipos diferentes (como cmd, powershell, e qualquer distro de wsl), além de ser bem rápido e customizável.

Vamos começar abrindo as configurações (Ctrl + , ).

1. Configurar perfil padrão

O primeiro passo é configurar o terminal para abrir automaticamente no WSL. Basta selecionar a sua distro no menu da primeira opção. No meu caso, Ubuntu 22.04 LTS

Pressione o botão de Salvar

2. Habilitar cópia de texto ao selecionar

No menu Interaction, basta marcar a primeira opção.

Pressione o botão de Salvar

3. Personalização de cores

No menu Color schemes podemos utilizar um esquema de cores já existente, ou criar um novo. No meu caso, vou configurar o Dracula Theme. O jeito mais fácil de instalar o Dracula é usar o botão Open JSON file no canto inferior direito, e inserir o JSON do site na lista schemes

4. Personalização de fontes

Mais abaixo vou mostrar como faço a configuração do powerlevel10k. Para utilizar ele (e qualquer tema mais complexo de terminal), você vai precisar instalar uma Nerd Font, pois elas vem com vários ícones. No caso do powerlevel10k, eles recomendam a fonte MesloLGS. Os links para download podem ser encontrados no github.

Para configurar a fonte, você pode ir na parte de Profiles, selecionar o Defaults e ir no menu Appearence, nas configurações adicionais.

Nesse mesmo menu você encontra opções gerais de aparência, como habilitar a transparência da janela, ou aplicar alguns efeitos. Eu uso a opacidade em 99%, e não uso nenhum dos efeitos.

Configuração do ZSH

Não vou entrar em detalhes, mas o ZSH (Z shell) é uma versão estendida do shell padrão de Linux, que traz uma boa performance, boas features de autocomplete e correção, além do suporte a plugins e temas, que é o principal foco aqui.

1. Instalar o zsh

echo "Installing ZSH"
sudo apt install zsh -y

2. Instalar o ohmyzsh

echo "Installing ohmyzsh"
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Após executar o comando, ele vai pedir sua confirmação para trocar o shell padrão para zsh

Após a confirmação, o seu terminal estará assim:

3. Instalação de plugins

O oh myzsh tem uma lista enorme de plugins. No dia a dia os que mais me impactam são o zsh-autosuggestions, que usa o seu histórico para recomendar comandos inteiros; e o zsh-syntax-highlighting. Hoje também vou aproveitar para instalar o asdf, que é um gerenciador de versões de várias linguagens; o dotenv, que permite a exportação de variáveis de ambiente de um arquivo .env automaticamente; e os plugins de autocomplete de algumas ferramentas como node, gcloud, docker, docker-compose.

echo "Installing zsh-autosuggestions"
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
echo "Installing zsh-syntax-highlighting"
git clone https://github.com/zsh-users/zsh-syntax-highlighting ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
echo "Installing asdf"
git clone https://github.com/asdf-vm/asdf.git ~/.asdf

O jeito mais fácil de habilitar os plugins é abrir o arquivo de configuração do terminal no VS Code, e inserir os valores manualmente

code ~/.zshrc

Basta procurar a variável plugins (no meu está na linha 73) e inserir todos os plugins que quer ativar. No meu caso, ficou assim:

plugins=(
  git 
  zsh-autosuggestions 
  zsh-syntax-highlighting 
  asdf 
  dotenv sudo
  gcloud 
  node npm 
  docker docker-compose 
  )

Você também pode fazer essa substituição por linha de comando:

file=".zshrc"
old_line="plugins=(git)"
new_line="plugins=(git zsh-autosuggestions zsh-syntax-highlighting asdf dotenv sudo gcloud node npm docker docker-compose)"

echo "Setting plugins on .zshrc"
sed -i "s|$old_line|$new_line|" "$file"

Configuração do powerlevel10k

O powerlevel10k é um tema de zsh que foca na flexibilidade do ambiente, mas com uma configuração bem simples.

Para instalar, basta fazer o download

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

E colocar o ZSH_THEME="powerlevel10k/powerlevel10k" no .zshrc

old_line='ZSH_THEME="[^"]*"'
new_theme='ZSH_THEME="powerlevel10k/powerlevel10k"'

echo "Setting the zsh theme to powerlevel10k"
sed -E -i "s|$old_line|$new_theme|" ".zshrc"

Agora basta reiniciar o terminal, e seguir a configuração interativa.

No final o meu terminal ficou assim:

Eu também faço algumas personalizações no .p10k.zsh, como para mostrar a configuração do gcloud o tempo todo (alterar nas linhas 1514 e 1515 para customizar o formato, e comentar as linha 1486 e 1529 para mostrar sempre o projeto)

Você pode navegar por esse arquivo e ler algumas das configurações, é possível personalizar completamente o comportamento do tema.

Instalação de ferramentas

Agora que o terminal está pronto, vamos instalar as ferramentas necessárias.

Vou usar:

Terraform
gcloud cli
gh cli
python, pip e venv
node
docker (ou podman)

Também vou criar um arquivo para colocar alias e funções customizadas.

1. Terraform

echo "Installing terraform"
sudo apt-get update && sudo apt-get install -y gnupg software-properties-common -y
wget -O- https://apt.releases.hashicorp.com/gpg | \
    gpg --dearmor | \
    sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg
gpg --no-default-keyring \
    --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
    --fingerprint
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
sudo apt update
sudo apt-get install terraform -y
terraform -install-autocomplete

2. Google Cloud CLI

Tive alguns problemas para instalar o gcloud, mas esses são os comandos que uso no Linux

echo "Installing gcloud cli"
sudo apt-get install apt-transport-https ca-certificates gnupg -y
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo tee /usr/share/keyrings/cloud.google.gpg
sudo apt-get update && sudo apt-get install google-cloud-cli -y

Para conseguir baixar, executei o seguinte:

echo "Removing duplicates"
sudo rm -rf /etc/apt/sources.list.d/google-cloud-sdk.list
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" \
| sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg \
| sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg

#Esse comando ficou parado esperando que eu digitasse o nome do arquivo. Eu copiei exatamente o que já tem nele

sudo apt update && sudo apt install google-cloud-sdk

Configurando o gcloud:

Basta executar o comando:

gcloud init

Ele vai gerar uma URL, que você pode clicar para ir para o navegador, onde vai precisar liberar permissão para o SDK

Ao final, basta copiar o código e colocar no seu terminal

3. Github CLI

Basta executar os comandos

echo "Installing gh cli"
type -p curl >/dev/null || (sudo apt update && sudo apt install curl -y)
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg \
&& sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg \
&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
&& sudo apt update \
&& sudo apt install gh -y

Em seguida, para configurar basta executar o comando e seguir a configuração interativa:

gh auth login

4. Python, pip e venv

echo "Installing python, pip and venv"
sudo apt install  python3-venv python3-pip -y

5. Node

echo "Installing nodejs with asdf"
asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git
asdf install nodejs latest
asdf global nodejs latest

6.a Docker

echo "Installing docker"
sudo apt remove docker-desktop
rm -r $HOME/.docker/desktop
sudo rm /usr/local/bin/com.docker.cli
sudo apt purge docker-desktop
sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release -y
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y

Configurar para conseguir usar sem sudo

sudo groupadd docker
sudo usermod -aG docker $USER

Configurar para que o serviço inicie sempre que abrir o terminal. Para isso colocamos o comando no arquivo /etc/wsl.conf. Para aplicar a alteração, é necessário reiniciar o wsl

echo "Setting docker service to start on boot"
echo -e '[boot]\ncommand="service docker start"' | sudo tee /etc/wsl.conf
wsl.exe --shutdown

6.b Podman

Podman é um outro gerenciador de contêineres, parecido com o docker. Sua instalação é mais simples, basta executar:

sudo apt install podman -y
pip3 install podman-compose

O comando podman pode ser usado em quase todos os casos em que o comando docker funciona. A exceção que encontrei é que ele ainda não tem o compose, como o docker. Para isso, basta instalar o podman-compose e executar podman-compose [comando]. É comum alguns tutoriais sugerirem que você crie um alias docker=podman .

O motivo para usar o Podman ao invés do Docker é que a instalação do docker sugerida para windows requer o Docker Desktop, que vai usar o WSL como backend (o que fizemos aqui é uma gambiarra, cortesia que ganhamos ao usar Linux). O problema é que a licença do Docker Desktop foi atualizada esse ano, definindo que a utilização gratuita não pode ser feita por empresas que tenham mais de 250 funcionários ou mais de 10 milhões de dólares de receita anual (fonte: Who’s required to pay for Docker Desktop?). Claro que isso não é um problema caso seu uso seja para estudos, uso pessoal ou para projetos open source não comerciais. Além disso, usuários de Windows estão acostumados a ter ferramentas de interface gráfica, que é o maior apelo do Docker Desktop. O Podman Desktop continua sendo 100% gratuito, mas sua instalação em Windows requer alguns ajustes que não vou comentar hoje.

7. Configurações de alias e ambiente em geral

Geralmente eu crio um arquivo ~/.profile , que deixo salvo como backup no meu github.

Basta criar o arquivo com suas funções, variáveis e apelidos. E depois acrescentar o comando source ~/.profile no fim do seu .zshrc

Eu costumo criar pastas para centralizar minhas service accounts e meus virtual environments de python, por isso tenho alguns comandos que fiz para facilitar

function set_google_credentials() {
  export GOOGLE_APPLICATION_CREDENTIALS="/home/$USER/.service_accounts/$1"
}

alias gconfig="gcloud config configurations"

Para gerenciar virtual environments, criei o pacote pyenvs, que está disponível no gist do github.

8. Gerenciamento de pastas e ambientes

Para usar o WSL, é recomendado que todos os arquivos que você vai utilizar estejam dentro do ambiente virtualizado. Ou seja, sempre que for criar um projeto novo (ou clonar um existente), abra o terminal e faça toda a execução dentro da home do seu usuário. Geralmente eu crio uma pasta Projects onde centralizo tudo.

mkdir Projects && cd Projects
mkdir exemplo && cd exemplo
npm init -y && echo "console.log('código de exemplo')">>index.js

Caso queira encontrar a pasta dos seus projetos pelo explorador de arquivos do windows, basta usar o comando abaixo dentro da pasta

explorer.exe .

Dica: no windows explorer, você pode fixar a pasta do seu wsl no menu lateral.

E por fim, sempre que vou abrir o VS Code eu abro pelo terminal, executando

code [caminho da pasta]

Finalizando

Talvez eu tenha esquecido de deixar alguma configuração, por isso fiquem a vontade para comentar aqui ou me marcar no twitter que eu trago uma atualização.

Espero que isso tenha sido útil para alguém, até a próxima!

Esse post foi publicado originalmente na minha página do github, e você pode acessar aqui:

Blog | cadumagalhaes.dev | Configuração do Windows para desenvolvimento

DEV Community: Cadu Magalhães

Roadmap de Engenharia de Dados para 2025

Introdução e Contexto Histórico

Nível 101 – Iniciante

1. Fundamentos de Bancos de Dados

1.1 Conceitos Teóricos

1.2 Exemplos Práticos

2. Pipelines de Dados

2.1 Conceitos Teóricos

2.2 Exemplos Práticos

3. Fundamentos de Arquitetura de Dados

3.1 Conceitos Teóricos

3.2 Exemplos Práticos

4. Desenvolvimento e Ferramentas Essenciais

4.1 Linguagem de Programação

4.2 SQL

4.3 APIs

Nível 201 – Intermediário / Preparando-se para o Mercado

1. Arquitetura de Dados Avançada

1.1 Conceitos Teóricos

1.2 Exemplos Práticos

2. Modelagem de Dados

2.1 Conceitos Teóricos

2.2 Exemplos Práticos

3. Transformação de Dados e Apache Spark

3.1 Conceitos Teóricos

3.2 Exemplos Práticos

4. SQL Avançado

4.1 Conceitos Teóricos

5. Fundamentos de Cloud Computing e DataOps

5.1 Cloud Computing

5.2 DataOps

6. Orquestradores de Dados

6.1 Conceitos Teóricos

7. No Code e Low Code em Engenharia de Dados

7.1 Conceitos Teóricos

8. Soft Skills e Gestão de Projetos

8.1 Conceitos Teóricos

9. Conceitos Avançados em Analytics Engineering

9.1 Conceitos Teóricos

Nível 301 – Avançado e Tendências

1. Processamento de Dados em Streaming e Arquiteturas em Tempo Real

1.1 Conceitos Teóricos

1.2 Exemplos Práticos

2. Observabilidade, Monitoramento e Documentação de Dados

2.1 Conceitos Teóricos

2.2 Exemplos Práticos

3. Data Quality e Governança

3.1 Conceitos Teóricos

3.2 Exemplos Práticos

4. Engenharia de Software Aplicada à Engenharia de Dados

4.1 Conceitos Teóricos

4.2 Exemplos Práticos

5. Mensageria e Integração em Tempo Real

5.1 Conceitos Teóricos

5.2 Exemplos Práticos

6. MLOps

6.1 Conceitos Teóricos

6.2 Exemplos Práticos

Módulo de Carreira e Desenvolvimento Profissional

1. Certificações

2. Preparação para Entrevistas

Sugestões de Livros e Referências Essenciais

Conclusões

Introdução à Engenharia de Dados

Um pouco de história

Principais responsabilidades de um Engenheiro de Dados

Principais habilidades de um Engenheiro de Dados

Comparação de carreiras

Onde esses cargos colaboram

Um exemplo do mundo real

Concluindo

Criação de conteúdo, open source e planos para 2025

Projetos Open Source

Criação de conteúdo

Cursos

Videos

Blog

Newsletter

Comunidade