DEV Community: Jean Cabral

Inteligência emocional

Jean Cabral — Thu, 02 Apr 2026 13:21:20 +0000

Inteligência emocional não diz respeito a “não ficar estressado”, “não errar” ou “estar sempre tranquilo".

Trata-se de perceber as situações antes de ultrapassar limites e ter a maturidade para mudar de direção.

Nos ambientes profissionais, o desafio é o tempo todo fazer entregas, cumprir prazos, gerar qualidade técnica e ser útil do ponto de vista produtivo.

Entretanto, existe uma característica que baseia todas essas coisas e que não costuma ser falada, que é a capacidade de lidar com relacionamentos, frustrações, pressão e consigo mesmo.

Em minha trajetória, algumas aprendizagens ficaram claras:

Nem toda resposta precisa ser dada na hora.
Saber a hora certa para falar é tão importante quanto ter coragem para fazer conversas difíceis.
Estar certo e estabelecer boas relações nem sempre andam juntas.
Pedir desculpas é sinal de maturidade e não de fraqueza.
Pessoas boas vão ter crescimento. Pessoas boas e emocionalmente equilibradas irão liderar.

No fundo, a carreira não é uma corrida de 100 metros. Ela é uma maratona.

E quem não aprende a lidar com suas emoções não terá condições de dar conta do crescimento a longo prazo.

Inteligência emocional não é soft skills.

É career skill.

Baixar a branch do PR: quando vale a pena testar localmente?

Jean Cabral — Sun, 06 Jul 2025 23:57:00 +0000

“Você costuma baixar a branch do PR para testar localmente?”

Essa pergunta parece simples, mas pode render boas discussões sobre qualidade de código, eficiência nas revisões e confiança no processo de desenvolvimento.

Nem todo pull request precisa ser executado localmente e quando isso se torna uma prática comum para todo PR, talvez o problema esteja em outro lugar.

Neste artigo, trago algumas reflexões sobre quando faz sentido testar um PR localmente e como isso se encaixa com a Pirâmide do Code Review uma abordagem (fantástica) que propõe uma hierarquia de prioridades ao revisar pull requests, inspirada na lógica da Pirâmide de Maslow.

🧱 A Pirâmide do Code Review

Antes de falar de testar localmente, vale conhecer essa estrutura simples que define níveis de prioridade em uma revisão de código:

Base da pirâmide (Functionality & Implementation) – O código faz o que deveria fazer?
Segunda camada (Testability & Coverage Tests) – O código está bem testado? É fácil de testar?
Terceira camada (Readability e Maintainability) – Dá para entender e manter esse código?
Topo da pirâmide (Code Style) – O código segue o padrão do time?

Essa pirâmide nos ajuda a revisar com foco no que realmente importa, e só subir a escada se os degraus abaixo estiverem ok.

✅ Quando vale a pena testar localmente?

Baixar a branch e rodar localmente faz sentido quando você está na base ou na segunda camada da pirâmide:

1. Implementação

O PR mexe em regras críticas (ex: valores financeiros, autenticação)?
Há dúvidas se o código faz realmente o que deveria?

2. Testabilidade

Os testes cobrem bem os casos de uso?
Existem fluxos manuais ou side effects que não estão claros no PR?

Outros motivos

É um PR que muda o comportamento da UI ou da API e você quer ver na prática.
O CI está instável e você quer validar o funcionamento local.
A descrição do PR está vaga, e rodar ajuda a entender o contexto.

❌ Quando isso pode virar um problema?

Se você sente necessidade de testar todo PR localmente, pode haver sinais de alerta:

Os testes automatizados não cobrem bem o código.
Os PRs não explicam claramente o que foi feito.
O CI não é confiável ou não tem validação de comportamento.
O código não é previsível: pequenas mudanças geram efeitos inesperados.

Se testar localmente se torna regra, é sinal de alerta: talvez o problema não esteja no código, mas na confiança no processo (e isso custa tempo).

⚖️ Prós e contras de testar localmente

✅ Pontos positivos

Dá mais confiança para aprovar.
Ajuda a pegar side effects.
Facilita entender contextos complexos.

❌ Pontos negativos

Torna a revisão mais lenta e pesada.
Cria dependência de ambiente local e setups manuais.
Pode mascarar problemas na qualidade do código ou na cobertura de testes.

🔁 E se o tempo for curto?

Use o bom senso. Nem todo PR precisa de execução local. Se for pequeno, direto e bem testado, a leitura de código pode ser suficiente. Confie na pirâmide: valide se a implementação corrige/cobre o problema de negócio, avalie os testes e só depois pense em rodar algo manualmente.

💬 Conclusão

Testar a branch do PR localmente é uma prática útil (mas não obrigatória). Ela deve ser usada com critério, como uma ferramenta de apoio para validar o que a leitura de código ou os testes automatizados não respondem sozinhos.

A pergunta que fica é:

Você testa localmente por necessidade, ou por desconfiança do processo?

Se for a segunda opção, talvez seja hora de investir em testes melhores, pipelines mais confiáveis e PRs mais bem descritos.

Retornando ao C# e explorando as inovações com C# in Depth

Jean Cabral — Fri, 27 Sep 2024 13:29:02 +0000

Após um período distante da programação e atuando em uma posição de gestão, decidi retomar os estudos de C#. No meu último contato com a linguagem, ela estava na versão 5, em 2014. Desde então, muita coisa mudou no ecossistema .NET, e senti a necessidade de me atualizar, especialmente em um cenário de carreira em Y, onde equilibrar habilidades técnicas e de liderança é essencial.

Neste post, trago um resumo do capítulo 15 do livro C# in Depth de Jon Skeet, um dos grandes nomes da comunidade .NET. Este capítulo aborda as principais inovações do C# 9, lançado em 2020.

Embora a quarta edição do livro cubra até o C# 8 (publicada em 2019), os conceitos apresentados são uma base sólida para entender a evolução da linguagem até versões mais recentes.

Por que voltar ao C#?

Depois de um período na cadeira de gerente, senti uma desconexão com algumas práticas e tecnologias atuais. O avanço rápido da tecnologia exige que, mesmo em posições de liderança, continuemos nos atualizando tecnicamente. Assim, retomar o C# foi uma forma de recuperar a confiança nas ferramentas modernas que estão sendo usadas no mercado e fortalecer minhas habilidades na linguagem.

Principais Funcionalidades do C# 9

O capítulo 15 de C# in Depth foca nas inovações do C# 9 que aprimoram o design de objetos imutáveis e introduzem novos paradigmas, como a programação funcional. Aqui estão as funcionalidades mais relevantes discutidas:

Records: Um novo tipo de referência que facilita a criação de objetos imutáveis, oferecendo igualdade baseada em valor e suporte a "with-expressions". Records são uma ótima escolha quando precisamos de classes que representem dados, com menos verbosidade.

var pessoa1 = new Person("Jean", "Cabral");
var pessoa2 = new Person("Jean", "Cabral");

// Comparação baseada em valor
Console.WriteLine(pessoa1 == pessoa2);  // True

// Uso de with-expressions para copiar com modificações
var pessoa3 = pessoa1 with { LastName = "Gama" };
Console.WriteLine(pessoa3);  // Output: Person { FirstName = Jean, LastName = Gama }

public record Person(string FirstName, string LastName);

Propriedades init-only: Propriedades que só podem ser configuradas durante a inicialização de um objeto. Isso permite um design mais seguro e imutável, reforçando a ideia de que, após criado, o estado do objeto não deve mudar.

public class Product
{
    public string Name { get; init; }
    public decimal Price { get; init; }
}

var product = new Product { Name = "MacBook", Price = 9200.00M };

// O código abaixo gera erro de compilação, pois a propriedade `init` não pode ser alterada após a inicialização
// product.Name = "ThinkPad";

Padrões aprimorados: O C# 9 introduziu novas possibilidades para correspondência de padrões, incluindo padrões lógicos e correspondência em tuplas. Esses recursos melhoram a legibilidade e expressividade do código.

static string GetGroupSizeMessage(int peopleCount) => peopleCount switch
{
    <= 1 => "Poucas pessoas.",
    <= 5 => "Pequeno grupo de pessoas.",
    <= 10 => "Médio grupo de pessoas.",
    _ => "Grande grupo de pessoas."
};

// Padrões lógicos em tuplas
static string ClassifyPerson(string name, int age) => (name, age) switch
{
    (_, < 18) => "Menor",
    _ => "Adulto"
};

Console.WriteLine(GetGroupSizeMessage(3));  // Output: Pequeno grupo de pessoas.
Console.WriteLine(ClassifyPerson("Jean", 40));  // Output: Adulto
Console.WriteLine(ClassifyPerson("Alice", 15));  // Output: Menor

Essas inovações refletem o quanto o C# evoluiu para oferecer mais segurança, concisão e expressividade, alinhando-se às demandas modernas de programação.

Nunca é tarde para aprender algo novo e recomeçar, seja para aprimorar nossas habilidades ou redescobrir a paixão pelo código.

Até breve.

Primeiros passos com o Apache Airflow

Jean Cabral — Tue, 04 May 2021 12:17:40 +0000

Introdução

Olar pessoal! Tive a oportunidade de conhecer o Apache Airflow e como achei muito bacana resolvi aprofundar um pouco nos conceitos dessa ferramenta. Este artigo vai ser algo bem introdutório, vou expor aqui alguns conceitos básicos sobre seu funcionamento, instalação e a criação de um fluxo de trabalho.

Airflow é uma plataforma criada pelo Airbnb, escrita em Python, que se tornou open-source em 2015 e logo depois cedida para o Apache Foundation.

O Airflow é um orquestrador de fluxos de tabalho. Com ele podemos programar, agendar e monitorar consultas de diversas fontes de dados, fazer tratamentos de forma simples. Veja alguns exemplos de casos de uso:

Criar um schedule, de forma periódica ou não, de migração de dados de uma tabela para outra;
Importar dados a partir de várias fontes e unificar em uma base centralizada.

Instalando

Primeiramente você deve ter um ambiente funcional com Python 3 antes de prosseguir ou se preferir rodar através do docker compose disponivel no site do Apache Airflow.

Optei pela instalação local para ficar mais didático. Iremos fazer a instalação do Airflow em sua versão estável (v2.0.2). Conforme sugerida em sua documentação oficial devemos fazer sua instalação usando o comando pip, ou seja, poetry e pip-tools não são recomendados.

Crie um diretório, onde ficará o projeto.



$ mkdir apache-airflow
$ cd apache-airflow
$ python3 -m venv .venv
$ source .venv/bin/activate

Agora vamos instalar o airflow, execute o comando abaixo:



$ pip install apache-airflow

Após a instalação, iremos definir uma variável de ambiente que indica onde o airflow está instalado.



$ export AIRFLOW_HOME=$PWD

Agora vamos inicializar o ambiente.



$ airflow db init

Após executar esse passo, notamos que ele cria o arquivo de configuração, um banco de dados sqlite onde será armazenados os metadados dos workflows, o arquivo de configuração do Airflow webserver e a um diretório de logs.

AIRFLOW_HOME

├── airflow.cfg

├── airflow.db

├── logs

└── webserver_config.cfg

Antes de subir o servidor do airflow, primeiramente vamos criar um usuário via cli do airflow, conforme o exemplo abaixo e definir sua senha.



$ airflow users create \
    --username admin \
    --firstname Jean \
    --lastname Cabral \
    --role Admin \
    --email seumelhor@email.com

Definindo o acesso, vamos agora subir o nosso servidor e acessar o Dashboard, executando o comando abaixo.



$ airflow webserver -p 8084

No comando acima estou executando o servidor na porta 8084, caso o parametro port nao seja passado ele será executado na porta padrão 8080. Para ver mais parametros execute airflow webserver --help.

Depois de efetuar o login, podemos ver a lista todos os workflows que vem por 'default' na instalação da ferramenta como exemplos, que servem de base para construirmos nossas pipelines. É possível ocultar esses exemplos alterando a propriedade load_examples no arquivo airflow.cfg.

O Dashboard do Airflow é bem intuitivo, através dele podemos ter controle das execuções e o histórico de cada um deles, log de execução, gráficos e etc.

Antes de criarmos o nosso primeiro Workflow, vamos ver uns conceitos importantes:

ETL: (Extract, Transform, Load): Procedimento geral para copiar de uma ou mais fontes de dados para um determinado destino;
DAG: (Directed Acyclic Graph): Coleção de todas as tarefas a serem executadas, organizadas de forma que reflete a relação e dependências entre elas. Em termos simples, a DAG é uma coleção de todas as pequenas tarefas que se unem para realizar uma grande tarefa.
Operator: Enquanto a DAG define como o fluxo vai ser executado, o Operator define o que será feito;
- BashOperator: Executa comandos no bash
- PythonOperator: Usado para chamar python function na DAG
- EmailOperator: Envio de email
- SimpleHttpOperator: Fazer requisições HTTP
Task: Instância de um Operator em execução;
Worker: Unidade de Trabalho (processo, container ou serviço) que realiza o processamento de uma tarefa de cada vez;
Scheduler: Unidade de agendamento requerido para orquestrar a execução de trabalhos agendados;

Criando nosso workflow

O fluxo de trabalho pode ser um cálculo simples, uma consulta no banco de dados, comando bash, script python, consultas Postgres, consultas BigQuery, etc. O fluxo de trabalho é dividido em uma ou mais tarefas que se relacionam entre si e formam um DAG.

Vamos criar um diretório chamado dags e dentro dele iremos criar um script python chamado print_date_file.py, que fará o seguinte: criar um arquivo texto num dado diretório e escrever a data atual.

Vamos ao código



import airflow
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import timedelta

Essas são as libs que iremos utilizar em nossa DAG. Como iremos usar o BashOperator precisamos importar ela da biblioteca do airflow.



default_args = {
    'owner': 'airflow',
    'start_date': airflow.utils.dates.days_ago(2)
}

Em default_args podemos definir um dicionário de parametros padrão que serão passados para o construtor de cada tarefa.



dag = DAG(
    dag_id='save_date_in_file_txt',
    default_args=default_args,
    schedule_interval=timedelta(days=1),
    dagrun_timeout=timedelta(minutes=60),
    tags=['print_date_file']
)



# Imprime a data na saída padrão.
t1 = BashOperator(
    task_id='print_date',
    bash_command='date',
    dag=dag
)

# Cria a pasta tmp caso ela não exista.
t2 = BashOperator(
    task_id="make_directory",
    bash_command="mkdir -p /home/jean/Code/PlayGround/apache-airflow/tmp",
    dag=dag
)

# Faz uma sleep de 5 segundos.
t3 = BashOperator(
    task_id='sleep',
    bash_command='sleep 5',
    retries=3,
    dag=dag
)

# Salve a data em um arquivo texto.
t4 = BashOperator(
    task_id='save_date',
    bash_command='date > /home/jean/Code/PlayGround/apache-airflow/tmp/date_output.txt',
    retries=3,
    dag=dag
)

Veja que nas tasks (t1, t2, t3 e t4) são valores que estão chamando a classe BashOperator e recebe os argumentos necessários para execução.

Cada tarefa tem seu task_id que define de forma única uma tarefa e argumentos necessários com base no operador que estamos utilizando.

Em nosso DAG, estamos executando quatro tasks diferentes, a primeira está imprime a data na stdout, a segunda cria o diretório tmp; a t3 faz uma pausa de 5 segundos e a última cria um arquivo texto, escreve a data, e é armazenado no diretório que criamos na t2.



t1 >> t2 >> t3 >> t4 #Fluxo de execução das tasks

Portanto, seu t1 óbvio deve ser executado antes de t2, portanto, definimos um fluxo de execução das tarefas.

Por fim, precisamos colocar nosso arquivo print_date_file.py na pasta DAG e, em seguida, ele será carregado no servidor automaticamente.

Em Graph View podemos ver a visualização do gráfico de tarefas:

Veja que a 'seta' indica a relação de dependência. Na task make_directory depende de print_date.

Bem, este foi um exemplo muito simples de como criamos tarefas e executamos o fluxo de trabalho. O intuíto foi trazer uma visão geral do Airflow, e o potencial que ele tem para auxiliar a criação de fluxos de trabalho em geral.

Até mais!

GatsbyJS: Configurando Eslint e Prettier no Visual Studio Code

Jean Cabral — Fri, 14 Feb 2020 18:18:07 +0000

Olá Pessoal! Neste artigo vamos configurar nosso editor para padronizar e formatar nosso código de forma automática, deixando-nos livres para pensar sobre a funcionalidade do nosso app.

Para isso, usaremos duas ferramentas. O ESLint que é um plugin utilizado para padronizar nosso código, como por exemplo a utilização de ponto e vírgula, tamanho máximo de caracteres em linhas dentre outros; e o Prettier que é utilizado para formatação do código deixando ele pretty, ou seja, 'bonito' 😀💅

⚙ Setup

Suponho que você já tenha o Visual Studio Code instalado e as extensões habilitadas ESLint e Prettier e um projeto GatsbyJS inicializado.

1. Instalando o ESLint como dependência do projeto

Execute comando abaixo para instalar osso package principal de linting o ESLint

$ yarn add eslint -D

Não precisaremos instalar o Prettier pois ele já vem empacotado junto com o projeto do Gatsby.

Depois de instalar o ESLint em nosso projeto vamos iniciar a configuração através do Wizard. Execute o comando abaixo e responda as perguntas:

$ yarn eslint --init

- How would you like to use ESLint?
> To check syntax, find problems, and enforce code style

- What type of modules does your project use?
> JavaScript modules (import/export)

- Which framework does your project use?
> React

- Does your project use TypeScript?
> No

- Where does your code run?
> Browser

- How would you like to define a style for your project? (Use arrow keys)
> Use a popular style guide ? AirBnb

- What format do you want your config file to be in?
> JavaScript

- Would you like to install them now with npm? (Y/n)
> Y

🗒 Ao final do processo eu apago o arquivo package-lock.json e rodo o comando yarn install para atualizar o yarn.lock. Pois o Gatsby utiliza o yarn como gerenciador de dependências do projeto.

Depois de terminado o processo será criado um arquivo .eslintrc.js na pasta raiz do nosso projeto, como também será instalado um série de dependências necessárias para o nosso guia de estilo escolhido.

Configurando o Prettier

Quando combinamos o ESLint e Prettier podemos enfrentar alguns problemas na formatação do nosso código, por que existem algumas regras comuns entre os pacotes, causando conflitos. Para contornamos essa situação, iremos instalar e configurar um pacote de configuração do Prettier para ESLint.

Vamos adicionar o seguinte pacote ao projeto que irá desabilitar todas as regras ESLint relacionadas à formatação.

$ yarn add eslint-config-prettier -D

Ao final do processo edite o arquivo .eslintrc.json para incluir essa configuração.

{
  "extends": ["airbnb", "prettier", "prettier/react"]
}

Este pacote desabilita todas as regras do ESLint relacionadas à formatação.

O próximo passo é o pacote é o Plugin Prettier para ESLint. Este plugin faz com que o Prettier seja executado como uma regra ESLint.

$ yarn add eslint-plugin-prettier -D

Para utilizá-lo, adicione, o código a seguir, no arquivo .eslintrc.json

"plugins": [
  "prettier"
],
"rules": {
  "prettier/prettier": "error"
}

Regras adicionais

Embora a guia de estilo do Airbnb seja excelente em seu conjunto de regras, faremos um configuração adicional nas regras do ESlint.

Usaremos a configuração existente no arquivo .eslintrc.json como ponto de partida e vamos adicionar algumas regras específicas ao Prettier em nossa configuração ESLint.

// .eslintrc.json
module.exports = {
  env: {
    browser: true,
    es6: true,
  },
  extends: [
    'plugin:react/recommended',
    'airbnb',
    'prettier', 'prettier/react'
  ],
  globals: {
    Atomics: 'readonly',
    SharedArrayBuffer: 'readonly',
  },
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    ecmaVersion: 2018,
    sourceType: 'module',
  },
  plugins: [
    'react',
    'prettier'
  ],
  rules: {
    "prettier/prettier": [
      "error",
      {
          "singleQuote": true,
          "printWidth": 120,
          "trailingComma": "es5"
      } 
    ],
    "react/jsx-filename-extension": [
      1,
      {
          "extensions": [
              ".js",
              ".jsx"
          ]
      }
  ],
  "react/prop-types": 0,
  "no-unused-vars": [
      "error",
      {
          "vars": "local",
          "args": "none"
      }
  ],
  "jsx-a11y/anchor-is-valid": [
      "error",
      {
          "components": [
              "Link"
          ],
          "specialLink": [
              "to",
              "hrefLeft",
              "hrefRight"
          ],
          "aspects": [
              "noHref",
              "invalidHref",
              "preferButton"
          ]
      }
  ]
  },
// Configuração para o Gatsby
  settings: {
    'import/core-modules': [
        "react"
    ]
}
};

Configuração para o Gatsby

  settings: {
    'import/core-modules': [
        "react"
    ]
}

Como iniciamos o projeto pelo Gatsby, iremos adicionar o pacote React para que o ESLint não nos avise sobre as importações não existentes.

2. Definindo as configurações do VSCode

Antes de prosseguir, vamos configurar o VSCode para executar o eslint e o prettier sempre que um arquivo for salvo.

Abra as configurações do usuário (em modo JSON) em pelo menu [File> Preferences > Settings] ou pelo atalho Ctrl+,.

  // Eslint Prettier
  "editor.formatOnSave": true,
  "[javascript]": {
    "editor.formatOnSave": false,
  },
  "[javascriptreact]": {
    "editor.formatOnSave": false,
  },
  "prettier.disableLanguages": [
    "js"
  ],
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "eslint.alwaysShowStatus": true,

Explicando por partes:

A entrada editor.formatOnSave faz com que o VSCode formate o documento sempre que salvar um arquivo.

  "editor.formatOnSave": true,

Desativa explicitamente a formatação para arquivos javascript, pois iremos formatar através do ESLint.

  "[javascript]": {
    "editor.formatOnSave": false,
  },
  "[javascriptreact]": {
    "editor.formatOnSave": false,
  },

Executa o ESLint em cada salvamento (com o sinalizador --fix).

  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },

Força o ESLint para sempre mostrar seu status na parte inferior do VSCode

  "eslint.alwaysShowStatus": true,

Considerações

Por fim, configuramos com sucesso o ESLint para trabalhar em conjunto com o Prettier. Agora somos notificados pelo VSCode sobre problemas de lint e sobre problemas de formatação. Sempre que salvarmos um arquivo .js, esses dois pacotes trabalharão juntos em nosso favor e farão um fix de todos os problemas. Bons códigos!