DEV Community: Felipe Cezar

Palantir: a empresa que transforma dados em decisões operacionais

Felipe Cezar — Fri, 15 May 2026 01:54:00 +0000

A Palantir é uma empresa americana de software conhecida por atuar em um ponto bem específico da tecnologia: integração de dados, análise operacional, inteligência artificial e tomada de decisão em ambientes complexos. Ela não é exatamente uma empresa de banco de dados, nem apenas uma empresa de IA, nem só uma consultoria. A melhor forma de entender a Palantir é pensar nela como uma plataforma que conecta dados espalhados, transforma esses dados em uma representação útil da realidade e permite que pessoas, sistemas e modelos de IA tomem decisões melhores em cima disso.

Origem

A Palantir foi fundada em 2003 e começou construindo software para a comunidade de inteligência dos Estados Unidos, principalmente em contextos ligados a investigações e operações de contraterrorismo. Com o tempo, a empresa expandiu sua atuação para clientes comerciais, porque muitas empresas grandes tinham um problema parecido: dados espalhados em vários sistemas, pouca visibilidade operacional e dificuldade de transformar informação em ação.

O nome da empresa vem dos “palantíri”, as pedras de visão do universo de Tolkien. A ideia combina bem com a proposta da companhia: permitir que organizações enxerguem melhor sistemas complexos.

O que a Palantir faz na prática

Na prática, a Palantir ajuda organizações grandes a responderem perguntas difíceis usando dados que normalmente estariam quebrados em vários lugares.

Por exemplo:

um exército pode usar dados de sensores, mapas, logística e inteligência para apoiar decisões operacionais;
um hospital pode cruzar dados de leitos, cirurgias, filas, equipes e pacientes para melhorar a gestão;
uma fábrica pode conectar dados de máquinas, fornecedores, peças, manutenção e produção;
uma empresa de energia pode monitorar ativos, prever falhas e melhorar confiabilidade operacional;
uma companhia aérea pode integrar dados de engenharia, manutenção, voos, peças e cadeia de suprimentos.

O ponto central é que a Palantir não tenta apenas mostrar dashboards bonitos. A proposta é criar um sistema onde dados, regras, permissões, fluxos de trabalho, modelos analíticos e ações estejam conectados.

Os principais produtos

A Palantir organiza sua plataforma em quatro produtos principais: Gotham, Foundry, Apollo e AIP.

Palantir Gotham

Gotham é a plataforma mais associada a governo, defesa, inteligência e segurança. Ela nasceu no contexto das agências de inteligência dos Estados Unidos e é usada para integrar dados sensíveis, identificar padrões, fazer análises operacionais e apoiar decisões em missões críticas.

É o produto que mais contribuiu para a imagem polêmica da empresa, justamente por sua ligação com defesa, guerra, inteligência e segurança pública.

Palantir Foundry

Foundry é a plataforma mais voltada para empresas, indústrias e grandes organizações comerciais. Ela funciona como uma camada de integração entre dados, operações e decisões.

Uma empresa pode usar Foundry para conectar sistemas internos, criar modelos de dados, desenvolver aplicações operacionais, acompanhar processos em tempo real e permitir que áreas diferentes trabalhem em cima da mesma visão da organização.

É aqui que entra um conceito importante da Palantir: a Ontology.

A Ontology é uma camada que representa os objetos reais de uma organização. Em vez de trabalhar apenas com tabelas soltas, a empresa passa a modelar coisas como clientes, pedidos, máquinas, aeronaves, pacientes, leitos, peças, fornecedores ou transações. Isso ajuda a transformar dados técnicos em algo que usuários de negócio, analistas, engenheiros e sistemas de IA conseguem entender e usar.

Palantir Apollo

Apollo é a plataforma de entrega e operação de software da Palantir. Ela permite implantar, atualizar e manter sistemas em ambientes diferentes: cloud pública, servidores próprios, ambientes regulados, redes militares ou infraestruturas mais restritas.

Esse produto é importante porque muitos clientes da Palantir não operam em ambientes simples. Governos, forças armadas, hospitais e grandes indústrias não podem simplesmente colocar tudo em uma cloud comum e sair usando. Eles precisam de controle, segurança, auditoria e funcionamento em cenários críticos.

Palantir AIP

AIP significa Artificial Intelligence Platform. É a plataforma de IA da Palantir, criada para conectar modelos de linguagem, agentes e automações aos dados e operações reais de uma organização.

A ideia do AIP é permitir o uso de IA generativa com controle, permissão, auditoria e supervisão humana. Em vez de um funcionário jogar informações sensíveis em um chatbot genérico, a empresa pode usar modelos de IA dentro de uma estrutura governada, conectada aos seus dados internos e aos seus processos reais.

Esse é um dos produtos mais importantes da fase atual da Palantir, porque posiciona a empresa diretamente na corrida de IA empresarial e governamental.

Clientes e setores relevantes

A Palantir trabalha tanto com governos quanto com empresas privadas. Em 2025, a empresa declarou ter 954 clientes. No mesmo ano, 54% da receita veio do segmento governamental e 46% do segmento comercial.

Entre os clientes e casos mais conhecidos estão:

Governo e defesa dos Estados Unidos

A Palantir tem uma relação histórica com agências de inteligência, defesa e órgãos públicos dos Estados Unidos. Seu software é usado em contextos como análise de dados, logística, inteligência, operações militares e tomada de decisão em ambientes críticos.

U.S. Army

O Exército dos Estados Unidos é um dos clientes relevantes da Palantir. Um exemplo é o Army Vantage, plataforma usada para integrar dados e apoiar decisões administrativas, financeiras e operacionais dentro do Exército.

NHS England

No Reino Unido, a Palantir participa da Federated Data Platform do NHS, o sistema público de saúde britânico. A proposta é conectar dados de hospitais, filas, leitos, cirurgias, altas e outros processos para melhorar a gestão operacional da saúde pública.

Esse caso também é um dos mais sensíveis e debatidos, porque envolve dados de saúde, privacidade e governança.

Airbus

A Airbus usa tecnologia da Palantir no contexto do Skywise, uma plataforma de dados voltada para a indústria da aviação. A ideia é conectar dados de engenharia, produção, manutenção, peças e operação para melhorar eficiência e tomada de decisão em uma cadeia extremamente complexa.

A bp usa Palantir Foundry em iniciativas ligadas à confiabilidade operacional. Em uma empresa de energia, pequenas melhorias em disponibilidade, manutenção e prevenção de falhas podem representar ganhos financeiros relevantes e redução de riscos operacionais.

Por que a Palantir é importante

A importância da Palantir vem do tipo de problema que ela resolve. Organizações grandes normalmente não sofrem por falta de dados. Elas sofrem porque os dados estão espalhados, duplicados, presos em sistemas legados, com permissões diferentes e sem conexão clara com decisões reais.

A Palantir tenta resolver esse caos criando uma camada comum entre dados, pessoas, regras, processos e IA.

Em termos técnicos, ela mistura elementos de:

data integration;
analytics;
governança de dados;
aplicações operacionais;
controle de acesso;
machine learning;
IA generativa;
workflow automation;
digital twin;
deployment em ambientes críticos.

Por isso, ela não se encaixa perfeitamente em uma categoria simples. Ela compete parcialmente com empresas de dados, BI, cloud, IA, consultoria e software empresarial, mas seu diferencial está na combinação de tudo isso em ambientes de missão crítica.

Por que a Palantir é polêmica

A Palantir também é uma empresa controversa. Isso acontece porque suas ferramentas são usadas em setores sensíveis, como defesa, inteligência, imigração, segurança pública e saúde.

A crítica principal não é apenas sobre tecnologia. É sobre poder.

Quando uma plataforma consegue integrar grandes volumes de dados e apoiar decisões de governos, exércitos ou sistemas de saúde, surgem perguntas importantes:

quem pode acessar esses dados?
quem audita o uso da plataforma?
quais decisões podem ser automatizadas?
existe risco de vigilância excessiva?
cidadãos têm controle ou transparência sobre seus dados?
como evitar abuso por parte de governos ou instituições?

Ao mesmo tempo, a empresa defende que seus produtos são feitos para ambientes com alto controle, segurança, permissões e auditoria. Essa tensão entre utilidade operacional e risco institucional é uma das razões pelas quais a Palantir aparece tanto em debates sobre tecnologia, IA, defesa e privacidade.

Entendendo o `if name == "main"` no Python de forma prática

Felipe Cezar — Wed, 13 May 2026 20:15:38 +0000

Se você já viu Python por algum tempo, provavelmente encontrou algo assim:

if __name__ == "__main__":
    main()

Esse trecho parece estranho no começo, mas a ideia é simples:

Ele serve para executar uma parte do código apenas quando aquele arquivo for executado diretamente.

Ou seja, ele ajuda a separar duas situações:

Quando um arquivo Python é executado diretamente.
Quando um arquivo Python é importado por outro arquivo.

E essa diferença importa bastante.

Primeiro: `main.py` não é a mesma coisa que `"main"`

Muita gente chama o arquivo principal de um projeto Python de main.py.

Por exemplo:

python main.py

Mas isso é só uma convenção.

O arquivo poderia se chamar:

python app.py

ou:

python calculadora.py

ou:

python sistema.py

O nome do arquivo não precisa ser main.py.

O ponto importante é:

O arquivo que você executa diretamente recebe o valor "__main__" dentro da variável __name__.

Então "__main__" não vem do nome main.py.

Ele vem do fato de aquele arquivo ser o ponto de entrada da execução.

O que é `name`?

Todo arquivo Python tem uma variável especial chamada __name__.

Ela muda dependendo de como o arquivo está sendo usado.

Se o arquivo for executado diretamente, __name__ vale:

"__main__"

Se o arquivo for importado por outro arquivo, __name__ vale o nome do próprio módulo.

Vamos ver isso na prática.

Exemplo 1: executando o arquivo diretamente

Arquivo: `calculadora.py`

print(__name__)

Agora execute no terminal:

python calculadora.py

A saída será:

__main__

Por quê?

Porque o arquivo calculadora.py foi executado diretamente.

Naquele momento, para o Python, ele é o arquivo principal da execução.

Exemplo 2: importando o arquivo

Agora imagine outro arquivo.

Arquivo: `app.py`

import calculadora

Execute:

python app.py

A saída será:

calculadora

Agora o calculadora.py não foi executado diretamente.

Ele foi apenas importado pelo app.py.

Então, dentro de calculadora.py, o valor de __name__ não é "__main__".

É "calculadora".

Então o que significa `if name == "main"`?

Significa:

"Execute esse bloco apenas se este arquivo for executado diretamente."

Veja este exemplo.

Arquivo: `calculadora.py`

def somar(a, b):
    return a + b

if __name__ == "__main__":
    print(somar(10, 5))

Se você executar:

python calculadora.py

A saída será:

Isso acontece porque calculadora.py foi executado diretamente.

Então, dentro dele:

__name__ == "__main__"

é verdadeiro.

Agora usando `calculadora.py` em outro arquivo

Arquivo: `app.py`

from calculadora import somar

resultado = somar(2, 3)
print(resultado)

Execute:

python app.py

A saída será:

Repare que o print(somar(10, 5)) que está dentro de calculadora.py não foi executado.

Por quê?

Porque agora quem foi executado diretamente foi o app.py, não o calculadora.py.

A situação fica assim:

Dentro de `app.py`

__name__ == "__main__"

Dentro de `calculadora.py`

__name__ == "calculadora"

Por isso este bloco não roda:

Arquivo: `calculadora.py`

if __name__ == "__main__":
    print(somar(10, 5))

O calculadora.py foi importado.

Ele não foi o arquivo principal da execução.

O que acontece se eu não usar isso?

O problema é que código solto dentro de um arquivo Python pode rodar automaticamente quando esse arquivo é importado.

Veja este exemplo.

Arquivo: `relatorio.py`

def gerar_relatorio():
    print("Gerando relatório...")

gerar_relatorio()

Agora outro arquivo importa esse módulo.

Arquivo: `app.py`

import relatorio

print("Sistema iniciado")

Execute:

python app.py

A saída será:

Gerando relatório...
Sistema iniciado

Mas repare: em app.py, você não chamou gerar_relatorio().

Mesmo assim, a função rodou.

Ela rodou porque estava solta dentro de relatorio.py.

Quando o Python importou relatorio.py, ele executou o código que estava no arquivo.

Por que isso é um problema?

Em um exemplo simples, isso só gera um print inesperado.

Mas em projetos reais, isso pode causar problemas maiores, como:

chamadas de API acontecendo sem querer;
consultas ao banco de dados só por causa de um import;
arquivos sendo criados, lidos ou alterados no momento errado;
funções rodando antes da hora;
testes ficando confusos;
código difícil de reaproveitar;
comportamento inesperado na aplicação.

Ou seja, sem esse cuidado, importar um arquivo pode fazer mais coisa do que deveria.

A versão correta

Agora veja a versão melhorada.

Arquivo: `relatorio.py`

def gerar_relatorio():
    print("Gerando relatório...")

if __name__ == "__main__":
    gerar_relatorio()

Arquivo: `app.py`

import relatorio

print("Sistema iniciado")

Execute:

python app.py

A saída será:

Sistema iniciado

Agora o relatório não é gerado automaticamente.

Por quê?

Porque relatorio.py foi importado, não executado diretamente.

Se você quiser executar o relatório diretamente, aí sim:

python relatorio.py

A saída será:

Gerando relatório...

Nesse caso, relatorio.py virou o arquivo principal da execução.

Então, dentro dele:

__name__ == "__main__"

é verdadeiro.

E a função `main()`?

É muito comum ver este padrão:

Arquivo: `main.py`

def main():
    print("Programa iniciado")

if __name__ == "__main__":
    main()

A função main() não é obrigatória.

Ela é apenas uma forma organizada de concentrar o ponto inicial do programa.

Você poderia escrever assim:

Arquivo: `main.py`

print("Programa iniciado")

Isso funciona.

Mas em projetos maiores, geralmente fica melhor separar as coisas.

Exemplo:

Arquivo: `main.py`

def carregar_dados():
    print("Carregando dados...")

def processar_dados():
    print("Processando dados...")

def salvar_resultado():
    print("Salvando resultado...")

def main():
    carregar_dados()
    processar_dados()
    salvar_resultado()

if __name__ == "__main__":
    main()

Esse padrão deixa claro qual é o fluxo principal do programa.

As funções ficam disponíveis para serem reutilizadas, mas a execução principal só acontece quando o arquivo é executado diretamente.

Então por que usar `if name == "main"`?

Use quando um arquivo Python pode ser:

Executado diretamente.
Importado por outro arquivo.

Ele evita que código rode sem querer durante um import.

Na prática, ele diz:

"Essa parte aqui só deve rodar se este arquivo for o ponto de entrada da aplicação."

Regra prática

Se o arquivo só tem funções, classes ou constantes, talvez você não precise dele.

Exemplo:

Arquivo: `operacoes.py`

def somar(a, b):
    return a + b

def subtrair(a, b):
    return a - b

Esse arquivo só oferece funções para outros arquivos usarem.

Agora, se o arquivo também tem uma execução principal, use o if.

Arquivo: `operacoes.py`

def somar(a, b):
    return a + b

def subtrair(a, b):
    return a - b

if __name__ == "__main__":
    print(somar(10, 5))
    print(subtrair(10, 5))

Assim, se você executar diretamente:

python operacoes.py

A saída será:

15
5

Mas se outro arquivo importar operacoes.py, esses prints não vão rodar automaticamente.

Resumo direto

Quando você executa um arquivo diretamente:

python app.py

dentro de app.py, o Python define:

__name__ = "__main__"

Quando você importa um arquivo:

Arquivo: `app.py`

import calculadora

dentro de calculadora.py, o Python define:

__name__ = "calculadora"

Então este código:

Arquivo: `calculadora.py`

if __name__ == "__main__":
    print("Rodando diretamente")

significa:

"Só execute esse bloco se o arquivo calculadora.py for executado diretamente."

Se rodar:

python calculadora.py

o bloco executa.

Se fizer:

Arquivo: `app.py`

import calculadora

o bloco não executa.

Conclusão

O if __name__ == "__main__" existe para evitar execução acidental de código quando um arquivo Python é importado.

Ele separa bem duas intenções:

importar um arquivo para usar suas funções, classes e variáveis;
executar um arquivo como programa principal.

A ideia central é simples:

"__main__" é o nome que o Python dá ao arquivo que foi executado diretamente.

Então este padrão:

Arquivo: `main.py`

def main():
    print("Programa iniciado")

if __name__ == "__main__":
    main()

significa:

"Execute main() apenas se este arquivo for o ponto de entrada do programa."

É simples, evita comportamento inesperado e deixa o código mais organizado.

O que é um RTOS e qual a diferença para um sistema operacional comum?

Felipe Cezar — Wed, 13 May 2026 01:04:05 +0000

Uma explicação prática sobre sistemas operacionais de tempo real, onde eles são usados e por que são diferentes de Windows, Linux e macOS.

Um RTOS é um Real-Time Operating System, ou Sistema Operacional de Tempo Real.

De forma direta:

RTOS é um sistema operacional feito para executar tarefas dentro de prazos previsíveis.

Ele não existe para abrir navegador, rodar editor de texto, tocar música ou gerenciar dezenas de aplicativos de usuário. Ele existe para controlar sistemas onde tempo de resposta importa.

Exemplo:

controlar motor;
ler sensor;
acionar freio;
disparar alarme;
enviar sinal para um dispositivo físico;
manter um equipamento funcionando em tempo previsível.

O foco de um RTOS não é ser “mais rápido”. O foco é ser previsível.

O problema que um RTOS resolve

Imagine uma esteira industrial.

Ela precisa:

detectar uma peça chegando;
verificar se a peça está na posição correta;
acionar um motor;
rejeitar peças defeituosas;
registrar o evento;
enviar dados para um servidor.

Nem todas essas tarefas têm a mesma urgência.

Parar ou acionar o motor no momento certo é crítico. Enviar estatística para o servidor pode esperar alguns milissegundos ou segundos.

Um RTOS ajuda justamente nisso: organizar tarefas com prioridades diferentes.

Sistema operacional comum vs RTOS

Um sistema operacional comum, como Windows, Linux desktop ou macOS, é feito para uso geral.

Ele precisa lidar com:

interface gráfica;
usuários;
arquivos;
rede;
drivers;
segurança;
navegador;
jogos;
editor de texto;
aplicativos diversos.

Ele tenta equilibrar vários programas ao mesmo tempo.

Um RTOS normalmente roda em outro tipo de ambiente: dispositivos embarcados, microcontroladores e sistemas que controlam hardware diretamente.

Exemplos:

ESP32;
STM32;
ARM Cortex-M;
sensores industriais;
dispositivos IoT;
drones;
robôs;
equipamentos médicos;
sistemas automotivos.

A diferença principal

A diferença central é esta:

Sistema operacional comum	RTOS
Foco em uso geral	Foco em tempo de resposta previsível
Roda aplicativos complexos	Roda tarefas específicas
Usa mais memória e processamento	Pode rodar em hardware limitado
Ideal para PCs, servidores e celulares	Ideal para microcontroladores e embarcados
Pode atrasar tarefas dependendo da carga	Prioriza tarefas críticas
Exemplo: Windows, Linux, macOS	Exemplo: FreeRTOS, Zephyr, VxWorks, QNX

“Tempo real” não significa instantâneo

Esse é um erro comum.

Tempo real não significa que algo acontece imediatamente. Significa que o sistema precisa responder dentro de um prazo definido.

Exemplo:

Se o sensor detectar obstáculo, o robô precisa parar em até 10 ms.

Se parar em 2 ms, ótimo.

Se parar em 8 ms, ainda está dentro do prazo.

Se parar em 200 ms, falhou.

O ponto não é velocidade máxima. O ponto é cumprir o prazo.

Exemplo prático: drone

Um drone precisa fazer várias coisas ao mesmo tempo:

ler sensores de movimento;
controlar motores;
estabilizar voo;
receber comandos do controle;
medir bateria;
enviar telemetria.

Algumas tarefas são mais importantes que outras.

Alta prioridade: controlar motores
Média prioridade: ler sensores
Baixa prioridade: enviar telemetria

Se a telemetria atrasar um pouco, provavelmente tudo bem.

Se o controle dos motores atrasar, o drone pode cair.

É esse tipo de problema que um RTOS ajuda a resolver.

Tasks: a unidade básica de trabalho

Em um RTOS, o programa costuma ser dividido em tasks.

Uma task é uma tarefa independente dentro do sistema.

Exemplo:

Task 1: ler sensor de temperatura
Task 2: controlar motor
Task 3: enviar dados por Wi-Fi
Task 4: atualizar display
Task 5: piscar LED de status

Cada task pode ter uma prioridade.

O RTOS decide qual task deve rodar em cada momento.

Escalonamento

O escalonador é uma das partes mais importantes de um RTOS.

Ele responde uma pergunta simples:

Qual tarefa deve rodar agora?

Em muitos RTOS, tarefas de maior prioridade passam na frente.

Exemplo:

Prioridade alta: parar motor
Prioridade média: ler sensor
Prioridade baixa: atualizar LED

Se a task de parar o motor precisa rodar, ela não deve esperar a task do LED terminar.

Isso é essencial em sistemas onde o software controla algo físico.

Interrupções

Outro conceito importante em sistemas embarcados é a interrupção.

Uma interrupção é um sinal vindo do hardware avisando que algo aconteceu.

Exemplos:

botão pressionado;
sensor disparou;
dado chegou pela serial;
timer venceu;
pacote chegou pela rede.

Fluxo simples:

Sensor detecta algo
↓
Hardware gera interrupção
↓
RTOS acorda uma task crítica
↓
Sistema responde ao evento

Em sistemas embarcados, interrupções são fundamentais porque o hardware não espera.

Hard real-time e soft real-time

Nem todo sistema de tempo real tem o mesmo nível de criticidade.

Hard real-time

Aqui, perder o prazo é falha grave.

Exemplos:

airbag;
freio automotivo;
controle de voo;
equipamento médico;
controle industrial crítico.

Se o sistema precisava responder em 5 ms e respondeu em 50 ms, ele falhou.

Soft real-time

Aqui, atraso é ruim, mas não necessariamente catastrófico.

Exemplos:

vídeo;
áudio;
jogos;
chamadas de voz;
interface de usuário.

Se atrasar, pode travar ou engasgar, mas normalmente não causa uma falha crítica.

FreeRTOS como exemplo

Um dos RTOS mais conhecidos é o FreeRTOS.

Ele é muito usado em microcontroladores e dispositivos IoT.

O FreeRTOS fornece recursos como:

criação de tasks;
prioridades;
filas;
semáforos;
mutexes;
timers;
gerenciamento básico de memória.

Ele não tenta ser um Linux.

Ele tenta ser um núcleo pequeno, leve e previsível para organizar tarefas em dispositivos limitados.

Por que não usar Linux em tudo?

Porque Linux é poderoso, mas nem sempre é adequado.

Linux é ótimo para:

servidores;
containers;
aplicações web;
bancos de dados;
interface gráfica;
arquivos;
redes complexas.

Mas, em muitos microcontroladores, Linux simplesmente é pesado demais.

Um dispositivo com pouca RAM, pouco armazenamento e tarefas bem específicas não precisa de um sistema operacional completo. Precisa de algo menor, previsível e direto.

É aí que entra um RTOS.

Exemplo prático: sensor IoT

Imagine um sensor IoT que mede temperatura e envia dados para a nuvem.

Ele pode ter tarefas como:

Task 1: medir temperatura
Task 2: verificar bateria
Task 3: conectar no Wi-Fi
Task 4: enviar dados
Task 5: entrar em modo de economia de energia

Esse dispositivo não precisa de navegador, interface gráfica ou sistema de arquivos complexo.

Ele precisa medir, transmitir e economizar energia.

Um RTOS pode organizar isso de forma mais simples e previsível.

Exemplo prático: equipamento médico

Imagine um equipamento que monitora sinais vitais.

Ele precisa:

ler sensores constantemente;
detectar valores perigosos;
acionar alarme;
mostrar dados na tela;
talvez enviar informações para outro sistema.

A leitura dos sensores e o alarme têm prioridade maior que atualizar algum elemento visual secundário.

Nesse tipo de cenário, previsibilidade importa muito.

Quando usar um RTOS?

Um RTOS faz sentido quando:

você está trabalhando com sistema embarcado;
existe controle direto de hardware;
há várias tarefas concorrentes;
algumas tarefas são mais críticas que outras;
tempo de resposta importa;
o hardware tem recursos limitados;
um loop simples já começou a ficar difícil de manter.

Quando não usar um RTOS?

Nem tudo precisa de RTOS.

Talvez você não precise de um RTOS se:

o programa é muito simples;
só existe um loop lendo sensor e piscando LED;
não há tarefas concorrentes;
não há prazo crítico;
o dispositivo já roda Linux tranquilamente;
você precisa de interface gráfica complexa ou aplicações de alto nível.

Às vezes, um loop simples resolve.

Usar RTOS sem necessidade pode adicionar complexidade.

Resumo direto

Um sistema operacional comum é feito para uso geral.

Um RTOS é feito para sistemas onde tempo de resposta e previsibilidade importam.

Em uma frase:

RTOS é um sistema operacional leve e previsível, usado principalmente em dispositivos embarcados para organizar tarefas críticas em tempo controlado.

Se o problema é abrir aplicativos, navegar na internet e usar interface gráfica, use um sistema operacional comum.

Se o problema é controlar sensores, motores, alarmes, robôs, drones ou dispositivos IoT com resposta previsível, um RTOS pode ser a escolha certa.

GPL vs DSL: entendendo a diferença entre linguagens de propósito geral e linguagens específicas

Felipe Cezar — Wed, 29 Apr 2026 15:48:24 +0000

Quando a gente começa a estudar programação, é comum colocar tudo no mesmo balaio e chamar qualquer coisa de "linguagem".

Python? Linguagem.

SQL? Linguagem.

HTML? Linguagem.

CSS? Linguagem.

Regex? Linguagem.

Só que existe uma diferença importante entre esses tipos de linguagem.

Algumas foram criadas para resolver praticamente qualquer tipo de problema. Outras foram criadas para resolver um problema muito específico dentro de um determinado contexto.

É aí que entram dois conceitos bem importantes:

GPL: General-Purpose Language
DSL: Domain-Specific Language

Observação rápida: aqui, GPL significa General-Purpose Language, não a licença GNU GPL.

1. GPL: General-Purpose Language

Uma GPL, ou linguagem de propósito geral, é uma linguagem criada para construir vários tipos de software diferentes.

Ela não está presa a um único domínio.

Com uma linguagem como Python, por exemplo, você pode fazer:

APIs web;
automações;
análise de dados;
inteligência artificial;
scripts;
jogos;
aplicações desktop;
ferramentas de linha de comando;
integração com bancos de dados.

Python é uma linguagem de propósito geral.

Outros exemplos seriam:

Java;
JavaScript;
C#;
Go;
C++;
Ruby;
PHP;
Kotlin;
Rust.

Essas linguagens geralmente possuem recursos completos de programação, como:

variáveis;
funções;
classes;
condicionais;
laços de repetição;
estruturas de dados;
tratamento de erros;
módulos;
bibliotecas.

Por exemplo, em Python:

def calcular_media(notas):
    total = 0

    for nota in notas:
        total += nota

    return total / len(notas)


notas = [8, 9, 7, 10]
media = calcular_media(notas)

if media >= 7:
    print("Aprovado")
else:
    print("Reprovado")

Aqui a linguagem permite criar lógica, controlar fluxo, usar função, usar for, usar if, manipular listas e assim por diante.

Esse é o tipo de liberdade que uma linguagem de propósito geral oferece.

2. DSL: Domain-Specific Language

Uma DSL, ou linguagem de domínio específico, é uma linguagem criada para resolver um problema dentro de um contexto específico.

Ela não tenta fazer tudo.

Pelo contrário: ela tenta fazer uma coisa muito bem.

Exemplos comuns de DSLs:

SQL, para consultar e manipular dados em bancos relacionais;
HTML, para estruturar páginas web;
CSS, para estilizar páginas web;
Regex, para trabalhar com padrões de texto;
YAML, para configuração;
Terraform HCL, para infraestrutura como código;
GraphQL, para consulta de dados em APIs;
Dockerfile, para definir imagens Docker.

A ideia de uma DSL é ser mais direta e expressiva dentro de um domínio.

Por exemplo, SQL foi criado para lidar com banco de dados:

SELECT nome, email
FROM usuarios
WHERE ativo = true
ORDER BY nome;

Esse código não parece Python, Java ou JavaScript.

Ele não está tentando criar uma aplicação completa. Ele está dizendo, de forma muito direta:

"Busque o nome e o email dos usuários ativos e ordene pelo nome."

SQL é ótimo para esse domínio: consulta de dados.

Mas você não usaria SQL para criar uma API web inteira, treinar um modelo de IA ou desenvolver um jogo.

3. Comparando GPL e DSL

A diferença central é esta:

Tipo	Significado	Objetivo	Exemplos
GPL	General-Purpose Language	Resolver vários tipos de problema	Python, Java, JavaScript, C#, Go
DSL	Domain-Specific Language	Resolver um problema específico	SQL, HTML, CSS, Regex, YAML

Uma GPL é como uma caixa de ferramentas completa.

Uma DSL é como uma ferramenta especializada.

Com Python, você consegue construir a casa inteira.

Com SQL, você resolve muito bem a parte relacionada aos dados.

Com CSS, você resolve muito bem a parte visual.

Com Regex, você resolve muito bem padrões em texto.

Cada uma tem seu papel.

4. Exemplo usando desenvolvimento web

Vamos imaginar uma aplicação web simples.

Você pode usar Python como linguagem principal:

from fastapi import FastAPI

app = FastAPI()

@app.get("/usuarios")
def listar_usuarios():
    return [
        {"id": 1, "nome": "Ana"},
        {"id": 2, "nome": "Carlos"}
    ]

Nesse caso:

Python é a linguagem de propósito geral;
FastAPI é o framework web;
Uvicorn pode ser o servidor que executa a aplicação.

Agora imagine que essa aplicação precisa consultar um banco de dados.

A consulta poderia ser escrita em SQL:

SELECT id, nome
FROM usuarios
WHERE ativo = true;

Aqui temos duas linguagens trabalhando juntas:

Python, como GPL;
SQL, como DSL.

Python organiza a lógica da aplicação.

SQL conversa com o banco de dados.

Cada um faz sua parte.

5. DSLs geralmente são mais limitadas?

Sim, mas isso não é necessariamente um problema.

Na verdade, essa limitação é parte da força delas.

Uma DSL não precisa ter todos os recursos de uma linguagem completa. Ela precisa ser clara, direta e eficiente dentro do seu domínio.

CSS, por exemplo, não foi criado para fazer lógica de negócio. Ele foi criado para estilizar páginas:

.card {
  background-color: #111827;
  color: white;
  padding: 24px;
  border-radius: 12px;
}

Você não usa CSS para criar uma API.

Mas para definir aparência visual, ele é extremamente expressivo.

A mesma coisa vale para Regex:

^[\w.-]+@[\w.-]+\.\w{2,}$

Esse padrão pode ser usado para validar algo parecido com um email.

Regex não serve para criar um sistema completo, mas é muito poderoso para trabalhar com padrões de texto.

6. Algumas DSLs podem ter lógica?

Sim.

É importante tomar cuidado para não simplificar demais.

Algumas DSLs possuem condicionais, funções, variáveis ou algum nível de lógica.

SQL, por exemplo, pode ter CASE, funções, subqueries, procedures e outros recursos dependendo do banco.

SELECT 
    nome,
    CASE 
        WHEN idade >= 18 THEN 'Maior de idade'
        ELSE 'Menor de idade'
    END AS status_idade
FROM usuarios;

Mesmo assim, SQL continua sendo uma linguagem voltada principalmente para o domínio de dados.

Ou seja, a pergunta principal não é:

"Essa linguagem tem if ou for?"

A pergunta melhor seria:

"Essa linguagem foi criada para resolver problemas gerais ou problemas de um domínio específico?"

7. Framework não é linguagem

Outro ponto importante: framework não é linguagem.

Python é uma linguagem.

FastAPI é um framework.

Java é uma linguagem.

Spring Boot é um framework.

JavaScript é uma linguagem.

Express é um framework.

Por exemplo:

Python + FastAPI
Java + Spring Boot
JavaScript + Express

A linguagem é a base.

O framework é uma estrutura construída em cima da linguagem para facilitar um tipo de desenvolvimento.

No caso de aplicações web, o framework ajuda a lidar com rotas, requisições HTTP, respostas, middlewares, autenticação e outras partes comuns.

8. Servidor também não é linguagem

Outro ponto que gera confusão: servidor também não é linguagem.

Uvicorn não é uma linguagem.

Tomcat não é uma linguagem.

Gunicorn não é uma linguagem.

Eles são servidores usados para executar ou servir aplicações.

Exemplo no mundo Python:

Python → linguagem
FastAPI → framework
Uvicorn → servidor ASGI

Exemplo no mundo Java:

Java → linguagem
Spring Boot → framework
Tomcat → servidor embutido/servlet container

Então, quando você acessa:

http://localhost:8000

Você não está acessando "o Python" diretamente.

Você está acessando um servidor rodando localmente, que por sua vez está executando sua aplicação Python.

9. Resumo final

A diferença entre GPL e DSL é uma daquelas coisas simples, mas que melhora muito a forma como a gente entende tecnologia.

Uma GPL é uma linguagem de propósito geral.

Ela serve para construir vários tipos de software.

Exemplos:

Python;
Java;
JavaScript;
C#;
Go.

Uma DSL é uma linguagem de domínio específico.

Ela serve para resolver um problema específico muito bem.

Exemplos:

SQL;
HTML;
CSS;
Regex;
YAML;
Dockerfile;
GraphQL.

No desenvolvimento real, a gente normalmente usa várias dessas linguagens juntas.

Uma API pode ser escrita em Python, consultar dados com SQL, retornar HTML, aplicar CSS e usar YAML para configuração.

Cada tecnologia entra em uma camada diferente do sistema.

E entender essa diferença ajuda a organizar melhor o pensamento:

Linguagem de propósito geral → constrói a aplicação
Framework → organiza o desenvolvimento
Servidor → executa/serve a aplicação
DSL → resolve tarefas específicas dentro do sistema

No fim, não é uma competição entre GPL e DSL.

É mais como uma caixa de ferramentas.

Algumas ferramentas fazem quase tudo.

Outras fazem uma coisa específica muito bem.

E um bom desenvolvedor aprende quando usar cada uma.

Web Crawling e Web Scraping

Felipe Cezar — Sun, 26 Apr 2026 17:30:28 +0000

1. Web Crawling (Rastreamento Web)

Tradução literal: Rastejar pela teia (web).

No jargão em português, chamamos de Rastreamento ou Indexação.

A Definição

O foco do Crawling não é pegar o conteúdo em si, mas sim descobrir caminhos.

Um Web Crawler, também chamado de Spider ou Bot, entra em uma página inicial, escaneia todos os links — tags <a href="..."> — que existem ali dentro, guarda esses links numa lista, entra em cada um deles, acha mais links, e continua fazendo isso num ciclo infinito até mapear a estrutura de um site inteiro ou da própria internet.

O Exemplo Clássico

O Googlebot.

O Google não tem funcionários digitando os sites novos que surgem. Ele tem robôs rastreadores que ficam pulando de link em link pela internet apenas "anotando" quais URLs existem para montar o catálogo do buscador.

No seu projeto de Artigos Científicos

Imagine que você entra na página principal de uma revista da Nature.

O Crawler é o script que vai entrar no sumário da edição daquele mês e varrer a tela apenas para descobrir e listar os 50 links individuais que levam para a página de cada artigo específico.

Ele não lê o artigo, ele só constrói a lista de URLs.

Ferramentas

Scrapy — o framework Python definitivo para isso
Apache Nutch

2. Web Scraping (Raspagem de Dados)

Tradução literal: Raspar a teia (web).

No jargão, chamamos de Raspagem de Dados ou Extração.

A Definição

O Web Scraping não quer saber de mapear o mundo; ele quer entrar em uma página específica, já com um endereço exato na mão, e extrair cirurgicamente uma informação útil de dentro daquela bagunça de código HTML.

Ele olha para a estrutura da página — as divs, classes e IDs — e puxa exatamente o texto ou arquivo que você mandou.

O Exemplo Clássico

Sites de comparação de preços, como o Buscapé.

Eles têm um script que entra na página exata de um modelo de TV na loja A, raspa só a div onde está escrito "R$ 2.500,00" e guarda no banco de dados deles.

No seu projeto de Artigos Científicos

Você pega aquela lista de 50 URLs que o seu Crawler descobriu.

Agora, o seu Scraper vai entrar em cada um desses links, procurar a tag HTML específica <div class="abstract-text"> para copiar o resumo do artigo, e depois procurar o botão <a id="download-pdf"> para forçar o download do arquivo.

Aqui, a ferramenta assíncrona httpx brilha muito para fazer os acessos rápidos, enquanto o Scraper faz a extração.

Ferramentas

BeautifulSoup — para raspar HTML estático
Selenium — para raspar sites dinâmicos
Playwright — para raspar sites dinâmicos que precisam clicar em botões ou rodar JavaScript

O Confronto Direto: Resumo

Característica	Web Crawling (Rastreamento)	Web Scraping (Raspagem)
Objetivo Principal	Mapeamento e Descoberta	Extração e Coleta de Dados
O que ele coleta?	Apenas URLs, links e a hierarquia do site	Textos, preços, imagens, tabelas, abstracts
Escala	Geralmente navega por milhares ou milhões de páginas de forma ampla	Geralmente foca em páginas específicas para extrair campos exatos
Analogia	O cartógrafo que desenha o mapa da cidade anotando o nome de todas as ruas	O carteiro que vai num endereço específico pegar uma encomenda exata

A Situação Real: Unindo os Dois no Fluxo ELT

No mundo real, para um projeto de engenharia de dados focado em IA, você constrói os dois trabalhando juntos em pipeline.

A Fase Crawler

Você roda o seu script, como o Scrapy, no portal de revistas científicas.

Ele navega pela paginação — "Próxima página", "Página 2", "Página 3" — e cospe para você um arquivo limpo só com uma coluna contendo 10.000 URLs de artigos que você não conhecia.

A Fase Scraper — Extract do ELT

Você pega essa lista de URLs e joga para o seu script de raspagem, usando httpx + BeautifulSoup.

Ele entra de cabeça em cada link, ignora as propagandas do site, raspa apenas os nomes dos autores, o abstract e puxa o PDF daquela página.

A Fase Load — ELT

Como você aprendeu a usar o ELT a seu favor, você salva tudo do jeito que veio direto no seu repositório bruto:

O abstract em um PostgreSQL ou MongoDB
O PDF no Amazon S3 ou em uma pasta local

E o trabalho de raspagem acaba aí.

A transformação pesada fica para depois.

Desmistificando a Nuvem: De VPN e VPS até SaaS, PaaS e IaaS (e onde o Render entra nisso)

Felipe Cezar — Thu, 16 Apr 2026 22:01:09 +0000

Você já deve ter passado por essa situação: você termina de codar, tudo roda perfeitamente no seu localhost, e aí você vira para um colega e diz: "Pronto, agora é só jogar na nuvem para deixar online".

Falar em "colocar na nuvem" está corretíssimo, mas a nuvem é como um grande shopping center. Você pode alugar um quiosque pequeno, uma loja inteira ou apenas comprar um produto pronto lá dentro.

Hoje em dia, a sopa de letrinhas (VPN, VPS, SaaS, PaaS, IaaS) confunde muita gente. Se você já se perguntou por que "antes tudo era VPN e agora tudo é VPS" ou onde ferramentas como o Render se encaixam nisso tudo, esse artigo é para você.

O Embate Clássico: VPN vs. VPS

As siglas diferem por apenas uma letra, mas resolvem problemas completamente diferentes na tecnologia.

VPN: A Rede Privada Virtual (Virtual Private Network)

Se você usou a internet entre 2017 e 2021, provavelmente foi bombardeado por youtubers fazendo propaganda de VPNs.

A VPN é um túnel blindado em uma estrada pública. Ela serve para roteamento seguro e privacidade. Quando você liga uma VPN, seu tráfego de internet passa por um túnel criptografado até um servidor em outro lugar.

Para que serve: Mascarar seu IP, proteger seus dados em redes Wi-Fi públicas ou simular que você está em outro país (para acessar o catálogo de um streaming gringo, por exemplo).
O que você faz lá: Clica em "Conectar" no aplicativo e apenas navega. Não há código envolvido.

VPS: O Servidor Virtual Privado (Virtual Private Server)

Se a VPN é um túnel, a VPS é um apartamento alugado num prédio de luxo (um Data Center).

A comunidade dev começou a falar muito de VPS por conta do movimento de self-hosting e da popularização do Docker. Cansados de pagar fortunas em serviços de nuvem caros, os desenvolvedores perceberam que poderiam alugar uma máquina Linux "crua" por 5 dólares, acessar via terminal e rodar o que quisessem.

Para que serve: Hospedar aplicações, APIs, bancos de dados, scripts que rodam de madrugada ou agentes de Inteligência Artificial.
O que você faz lá: Acessa via SSH (terminal), instala o Ubuntu, configura o Docker, clona seu repositório e sobe seus contêineres. É você quem manda na máquina.

As Camadas da Nuvem (IaaS, PaaS, SaaS)

Quando você diz "vou colocar na nuvem", você precisa escolher qual nível de dor de cabeça (e de controle) você quer ter. É aqui que entram os modelos de serviço.

1. IaaS (Infrastructure as a Service) - A Fundação

É a infraestrutura bruta. Você aluga a máquina e se vira com o sistema operacional.

Onde a VPS entra: Uma VPS (da DigitalOcean, Linode, AWS EC2) é exatamente um IaaS.
Exemplo de uso: Digamos que você construiu um backend complexo, como uma KB Orchestrator API em Python, que precisa rodar contêineres e orquestrar buscas com LLMs. Numa VPS (IaaS), você tem controle total para instalar o Docker e configurar as portas exatamente como precisa.

2. PaaS (Platform as a Service) - A Plataforma Pronta

Aqui você não quer saber de configurar Linux ou dar apt-get update. Você só quer que seu código rode.

Onde o Render entra: Plataformas como Render e o antigo Heroku são PaaS. Elas ficam no meio-termo perfeito. Você conecta seu GitHub, diz "meu código é em Python" ou "roda esse Dockerfile", e a plataforma cuida da infraestrutura, dos servidores e dos certificados de segurança por baixo dos panos. É o paraíso para quem quer deploy rápido sem virar administrador de sistemas.

3. SaaS (Software as a Service) - O Produto Final

É o topo da pirâmide. Você não programa nada, não gerencia servidor e não vê o código. Você apenas paga (ou usa de graça) para utilizar o software pelo navegador.

Exemplos: Notion, Canva, Figma, Google Docs. Você é apenas o consumidor final do serviço.

Na prática: Onde eu hospedo meu projeto?

Para simplificar sua tomada de decisão no próximo deploy:

Front-end estático ou sites simples (HTML/CSS/JS, React): Se você quer apenas subir o seu portfólio (como o meu felipecezar.dev, por exemplo), use plataformas focadas em front-end como Vercel, Netlify ou GitHub Pages. É rápido, gratuito e não exige servidor.
Backend, APIs, Banco de Dados (sem dor de cabeça): Vá de PaaS (Render, Railway). É a melhor opção para colocar uma aplicação conectada a um banco de dados online rapidamente, sem gerenciar a infraestrutura Linux.
Controle total, Arquiteturas Complexas ou Self-Hosting barato: Vá de VPS (IaaS). Alugue sua máquina na nuvem, instale o Docker e faça a orquestração com suas próprias mãos.

E aí, onde você tem hospedado seus últimos projetos? Deixa aí nos comentários!

Desmistificando a Frase: "Aí ele serializa isso para JSON HTTP e manda pro cliente"

Felipe Cezar — Wed, 15 Apr 2026 12:36:20 +0000

Se você está mergulhando no desenvolvimento web, em algum momento vai ouvir de um desenvolvedor mais experiente a clássica frase: "Aí a gente pega o objeto, serializa isso para JSON, joga no HTTP e manda pro cliente." Mas o que isso significa na prática? O que exatamente é esse "isso"? Como ocorre essa "serialização" e quais são as armadilhas no meio do caminho? Vamos quebrar essa frase e entender os bastidores da comunicação na web.

1. O que é o tal do "Isso"? (O Problema da Memória)

Para entender a frase, precisamos primeiro olhar para o "isso".

O "isso" é simplesmente a variável ou o objeto que contém os dados da sua aplicação e que está "vivo" na memória RAM do seu servidor (Back-end).

Imagine que seu back-end foi escrito em Python. Você foi no banco de dados e montou o perfil de uma cliente. O "isso" é a variável perfil_cliente:

import datetime

# Esse objeto abaixo é o nosso famoso "isso".
# Ele só existe, funciona e faz sentido dentro da memória do Python.
perfil_cliente = {
    "nome": "Ana da Silva",
    "idade": 30,
    "saldo_conta": 1540.50,
    "pode_comprar": True,                      # No Python, True é com "T" maiúsculo
    "data_cadastro": datetime.date(2023, 1, 5) # Um objeto complexo nativo do Python!
}

Qual é o problema de enviar "isso" do jeito que está?
O navegador do usuário (Front-end) pode estar rodando JavaScript, Swift (iOS) ou Kotlin (Android). Nenhuma dessas linguagens sabe o que é um objeto datetime.date do Python. Elas também não entendem que True com "T" maiúsculo é um valor booleano.

Se você tentar enviar o objeto direto da memória (os bytes crus daquele objeto Python) pelo cabo de rede, o aplicativo do usuário vai receber lixo ilegível e quebrar. Eles precisam de uma "língua franca".

2. A Solução: Serialização e o Formato JSON

Para que o Python converse com o JavaScript, usamos o JSON (JavaScript Object Notation). Ele é, essencialmente, uma grande string de texto padronizada e universal.

A Serialização é a ação de pegar aquele objeto complexo e cheio de regras locais (o "isso") e achatá-lo, transformando-o em uma simples string de texto JSON. É como desmontar um castelo de Lego e colocar as peças numa caixa com um manual de instruções, para que quem receba possa reconstruir do outro lado (o que chamamos de Desserialização).

Quem faz o trabalho sujo? (Os Métodos de Serialização)

Toda linguagem de programação moderna tem ferramentas nativas para fazer isso:

No Python: Usamos a biblioteca padrão json. O método principal é o json.dumps().
No JavaScript (Node.js/Browser): Usamos o JSON.stringify(objeto).
No C# (.NET): Usamos System.Text.Json.JsonSerializer.Serialize(objeto).

Hoje em dia, a maioria dos frameworks web faz isso por debaixo dos panos. Se você usa o Express.js no Node, por exemplo, o método res.json(usuarioData) já pega o objeto, roda um stringify e prepara para o envio automático.

3. O "Depois": Como fica o JSON HTTP?

Quando o servidor finalmente "joga no HTTP e manda pro cliente", o que viaja pelo cabo da internet não é o objeto, mas sim um pacote de texto purinho.

Voltando ao nosso exemplo da Ana, é exatamente isto aqui que sai do servidor em direção ao celular do cliente:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 114

{
  "nome": "Ana da Silva",
  "idade": 30,
  "saldo_conta": 1540.50,
  "pode_comprar": true,
  "data_cadastro": "2023-01-05"
}

Repare na mágica da conversão:

O Envelope HTTP: As três primeiras linhas dizem ao cliente: "Deu tudo certo (200 OK) e o conteúdo da mensagem é texto formatado em JSON".
O Booleano: O True do Python virou true minúsculo (regra do JSON).
A Data: O objeto complexo datetime.date foi achatado e virou uma simples string de texto "2023-01-05".

Quando o aplicativo recebe esse texto, ele faz a Desserialização (usando algo como JSON.parse() no JavaScript), transformando o texto de volta em um objeto vivo na memória do celular.

4. Onde o bicho pega? (Problemas Comuns)

A serialização não é à prova de falhas. Aqui estão os problemas que todo dev vai enfrentar:

Funções e Métodos não são serializáveis: O JSON guarda dados, não comportamento. Se o seu objeto tem uma função tipo calcularIdade(), ela será completamente ignorada e removida na hora de virar JSON.
Referências Circulares (O terror do Node.js): Imagine um objeto "Pessoa" que tem uma propriedade apontando para o seu "Chefe", e o "Chefe" tem uma propriedade apontando de volta para a "Pessoa". Quando o serializador tenta transformar isso em texto, ele entra num loop infinito e sua aplicação quebra (o famoso erro TypeError: Converting circular structure to JSON).
Perda de precisão e Datas: O JSON não tem um tipo nativo para "Data". Tudo vira texto. O cliente precisa saber que aquela string "2023-01-05" deve ser convertida para data novamente. Além disso, números incrivelmente grandes (BigInt) podem perder precisão dependendo de como a linguagem de destino os lê.

5. Dá para mandar sem serializar?

Sim! Nem toda resposta HTTP precisa ser JSON. Se você não serializar, você está mandando os dados "crus" ou em outros formatos, e isso é perfeito dependendo do caso:

Arquivos e Imagens: Se o cliente pede a foto de perfil do usuário, o servidor não transforma a foto em JSON. Ele simplesmente envia os bytes binários da imagem pela rede e avisa no cabeçalho: Content-Type: image/jpeg.
Páginas Web Clássicas: Quando você acessa um site, o servidor envia texto em formato HTML puro (Content-Type: text/html). O navegador sabe ler isso nativamente para renderizar a página.
Texto Plano: Você pode simplesmente retornar uma string solta com Content-Type: text/plain.

O JSON entra em cena especificamente quando precisamos trafegar dados estruturados (listas, dicionários, atributos) entre sistemas que falam "idiomas" diferentes.

Resumo da Ópera

Quando dizemos "serializa isso para JSON HTTP", estamos falando do processo universal de sobrevivência dos dados na web: pegar uma estrutura complexa em uma linguagem, traduzi-la para um texto universal (JSON), empacotá-la em um envelope de transporte (HTTP) e despachá-la para o destino. Entender esse ciclo é o primeiro grande passo para dominar o desenvolvimento de APIs!

O Lado 'Falsy' da Força: Entendendo o poder do 'if not' em Python

Felipe Cezar — Tue, 14 Apr 2026 19:31:47 +0000

Imagine a cena: você está construindo uma aplicação, talvez consumindo uma API ou limpando um dataset, e precisa verificar se uma lista de dados retornou vazia antes de processá-la.

Se você vem de linguagens com tipagem mais estrita e sintaxe mais verbosa, como Java, seu primeiro instinto provavelmente será escrever algo assim:

dados_recebidos = []

# O jeito "clássico" de checar se está vazio
if len(dados_recebidos) == 0:
    print("Nenhum dado para processar. Encerrando...")

Ou, pior ainda, comparar com uma lista vazia:

if dados_recebidos == []:
    print("Nenhum dado para processar.")

Funciona? Sim, perfeitamente. Mas não é nada elegante. No mundo do Python, valorizamos a legibilidade e o minimalismo. Queremos um código que se leia quase como um texto em inglês.

É aqui que a magia acontece e o código acima se transforma nisso:

dados_recebidos = []

# O jeito "Pythonic"
if not dados_recebidos:
    print("Nenhum dado para processar. Encerrando...")

Lindo, direto e sem poluição visual. Mas... por que isso funciona? Como o Python sabe que "não dados_recebidos" significa que a lista está vazia? A resposta está em um conceito fundamental da linguagem: os valores Truthy e Falsy.

Tudo no Python é avaliado como um Booleano

Por baixo dos panos, quando você coloca uma variável em uma estrutura condicional (como if ou while), o Python tenta converter esse objeto para um valor booleano (True ou False) usando a função embutida bool().

Em vez de exigir que a expressão resulte estritamente em um booleano literal, o Python é flexível. Ele assume que todos os objetos são verdadeiros (Truthy), exceto alguns casos muito específicos que são considerados falsos (Falsy).

A Galeria dos Falsy

Quais são esses valores que o Python considera como False? A lista é pequena, intuitiva e representa a ideia de "vazio" ou "nada":

Constantes de nulidade e falsidade: None e False.
Zero em qualquer tipo numérico: 0 (int), 0.0 (float), 0j (complex).
Coleções ou sequências vazias: * Strings vazias: ""
- Listas vazias: []
- Tuplas vazias: ()
- Dicionários vazios: {}
- Sets vazios: set()

Se o seu objeto estiver nessa lista, o Python dirá que ele é Falsy. Se não estiver, ele é Truthy.

print(bool([]))     # Saída: False (Falsy)
print(bool([1, 2])) # Saída: True (Truthy)
print(bool(""))     # Saída: False (Falsy)
print(bool("Olá"))  # Saída: True (Truthy)

O Casamento Perfeito: `Falsy` + `if not`

Agora que sabemos o que é Falsy, o comportamento do if not fica óbvio. O operador not em Python simplesmente inverte o valor booleano da expressão.

O Python pega a sua variável (ex: uma lista vazia []).
Ele avalia o valor booleano dela (lista vazia é Falsy, ou seja, False).
O operador not inverte esse valor (not False vira True).
O bloco do if é executado!

Veja como isso torna a validação de variáveis incrivelmente limpa em cenários reais:

Cenário 1: Validando strings

nome_usuario = input("Digite seu nome: ")

# Se o usuário apenas apertar Enter, nome_usuario será "", que é Falsy.
# not "" vira True.
if not nome_usuario:
    print("O nome não pode ficar em branco!")

Cenário 2: Buscando um registro em um banco de dados

# Simulando a busca de um usuário que não existe
resultado_db = None 

# None é Falsy. not None vira True.
if not resultado_db:
    print("Usuário não encontrado.")

Cuidado com as armadilhas!

O poder do Falsy é incrível, mas exige responsabilidade. O maior erro ao usar o if not é quando o número 0 ou o valor False são respostas válidas para o seu contexto de negócio.

Imagine que você está registrando a pontuação de um teste:

pontuacao = 0

if not pontuacao:
    print("Você não fez o teste.")

Ops! O aluno fez o teste sim, ele apenas tirou zero. Como 0 é um valor Falsy, o código caiu no if.

Nesse tipo de situação, a validação implícita do Falsy não serve. Você precisa ser explícito:

# Checagem correta se o valor pode legitimamente ser zero
if pontuacao is None:
    print("Você não fez o teste.")

Conclusão

Entender os conceitos de Truthy e Falsy é um rito de passagem no aprendizado do Python. Isso permite que você abandone verificações desnecessárias de tamanho (len() == 0) e comparações com valores vazios (== "").

Ao abraçar o if not, você escreve um código mais minimalista, legível e direto ao ponto — focando no que realmente importa: impacto e resultados.

E você? Costumava usar len() == 0 nos seus primeiros códigos em Python? Deixe aí nos comentários!

🧠 Agentes de IA também precisam esquecer: Entendendo TTL e Expiração de Memória

Felipe Cezar — Mon, 13 Apr 2026 14:52:33 +0000

Imagine a seguinte cena: você acaba de criar o seu primeiro Agente de IA. Ele é brilhante, rápido e responde aos seus usuários com uma precisão assustadora. No primeiro dia, é só alegria. Na primeira semana, ele continua ótimo.

Mas no trigésimo dia, algo estranho acontece. O seu agente começa a demorar 15 segundos para responder a um simples "Olá". Pior ainda, ao checar a sua fatura de consumo de API (seja da OpenAI, Google ou Anthropic), você toma um susto: os custos explodiram. Além disso, o agente começa a se confundir, misturando o contexto de uma conversa de três semanas atrás com a dúvida atual do usuário.

O que deu errado? Você construiu um agente com memória fotográfica eterna, mas esqueceu de ensiná-lo a esquecer.

É aqui que entra um dos conceitos mais importantes (e subestimados) na arquitetura de Agentes de IA: o TTL (Time-To-Live) e as estratégias de expiração de contexto.

🕰️ O que é TTL, afinal? (A Base)

Se você vem do mundo de redes ou de banco de dados, provavelmente já conhece essa sigla. TTL (Time-To-Live), ou Tempo de Vida, é um mecanismo que define por quanto tempo um pedaço de dado deve existir em um sistema antes de ser descartado.

Nas Redes: É o que impede que um pacote de dados fique vagando pela internet para sempre em um loop infinito (quando o TTL zera, o pacote morre).
Nos Bancos de Dados (como Redis): É o que faz um dado em cache desaparecer após algumas horas, garantindo que você não acesse informações desatualizadas.

No contexto de Agentes de IA, o TTL e a "expiração" referem-se a como gerenciamos a janela de contexto (a memória de curto prazo) do modelo e os caches de respostas. ---

💸 Por que a "Amnésia Controlada" é uma Feature, e não um Bug?

Os Modelos de Linguagem (LLMs) não têm estado (stateless). Para que eles "lembrem" de uma conversa, você precisa re-enviar todo o histórico de mensagens a cada nova interação. Se você não expirar essas informações, enfrentará três grandes vilões:

O Limite Físico (Context Window): Todo LLM tem um limite máximo de tokens que consegue processar por vez (ex: 8k, 128k, 1M). Se a conversa passar disso, a API simplesmente rejeita a requisição.
A Falência Financeira (Custos): As APIs cobram por tokens de entrada. Se você envia um histórico de 10.000 tokens a cada nova mensagem "ok", você está queimando dinheiro à toa.
A Perda de Foco (Sinal de Ruído): Quanto mais longa a janela de contexto, mais difícil fica para a IA prestar atenção na instrução mais recente (o famoso problema do "Lost in the Middle", onde a IA esquece o que estava no meio do texto gigante).

🛠️ Como o TTL funciona na prática com IA? (Estratégias)

Implementar expiração em agentes não é apenas colocar um "timer". Existem diferentes formas de fazer seu agente esquecer de maneira inteligente. Vamos explorar as principais:

1. TTL Baseado em Tempo (O Clássico)

Aqui, o TTL funciona exatamente como no Redis. Se o usuário ficou inativo por "X" minutos, a sessão é encerrada e a memória de curto prazo é apagada.

Caso de uso ideal: Chatbots de atendimento ao cliente (SAC). Se o cliente abriu um chamado às 10h da manhã e mandou outra mensagem às 20h, provavelmente é um assunto totalmente novo. Manter o contexto anterior só vai atrapalhar e custar caro.

2. Expiração por Janela Deslizante (Sliding Window)

Em vez de tempo cronológico, o limite é baseado na quantidade de interações. Você configura o agente para manter apenas as últimas N mensagens no array de contexto.

Como funciona: Se o limite é 10, assim que a 11ª mensagem entra, a mensagem número 1 (a mais antiga) é deletada do array enviado ao LLM.
Caso de uso ideal: Assistentes pessoais e agentes de linha de comando (CLI) que precisam de contexto imediato, mas não do histórico completo da vida do desenvolvedor.

3. Expiração Baseada em Tokens (Token Limits)

Mais precisa que a janela deslizante. Você calcula ativamente os tokens (usando bibliotecas como o tiktoken) e expira as mensagens mais antigas apenas quando o limite financeiro ou técnico (ex: máximo de 4.000 tokens de memória) é atingido.

4. Cache TTL (Prevenindo chamadas repetidas)

Agentes muitas vezes usam ferramentas (Tools/Function Calling) para buscar dados, como consultar a previsão do tempo ou o preço do dólar.
Se o agente consultar o dólar agora, e outro usuário perguntar a mesma coisa 1 minuto depois, não há por que gastar tokens e latência chamando a API de novo. Usa-se um Cache de Resposta com TTL de alguns minutos. Bateu no cache? O agente responde instantaneamente. O TTL expirou? Ele chama a ferramenta novamente.

👨‍💻 Storytelling em Código: Construindo a Memória

Como isso se parece no código? Abaixo, um exemplo conceitual simples em Python de um Agente gerenciando sua própria memória com Sliding Window e verificação de TTL por tempo inativo:

import time

class AgentMemory:
    def __init__(self, max_messages=10, ttl_seconds=3600):
        self.messages = []
        self.max_messages = max_messages
        self.ttl_seconds = ttl_seconds
        self.last_interaction = time.time()

    def add_message(self, role, content):
        current_time = time.time()

        # 1. TTL por Tempo: Se passou muito tempo desde a última mensagem, limpa a memória!
        if (current_time - self.last_interaction) > self.ttl_seconds:
            print("⏳ TTL expirado. O agente esqueceu a conversa anterior.")
            self.messages = []

        # Adiciona a nova mensagem
        self.messages.append({"role": role, "content": content})
        self.last_interaction = current_time

        # 2. Expiração por Quantidade (Sliding Window): Remove os itens mais velhos
        if len(self.messages) > self.max_messages:
            # Mantém apenas as últimas 'max_messages' mensagens
            self.messages = self.messages[-self.max_messages:]
            print("✂️ Limite de contexto atingido. Mensagem mais antiga descartada.")

    def get_context(self):
        return self.messages

# Testando nosso agente
memory = AgentMemory(max_messages=3, ttl_seconds=10)

memory.add_message("user", "Qual a capital do Brasil?")
memory.add_message("assistant", "A capital é Brasília.")
memory.add_message("user", "Quantos habitantes tem lá?")
memory.add_message("assistant", "Tem cerca de 3 milhões.") # Aqui atingiu o limite de 3+1 = 4. O primeiro "user" será cortado!

🧠 E se eu precisar lembrar para sempre? (Memória de Longo Prazo)

"Mas eu quero que meu agente lembre que eu sou alérgico a camarão para sempre!"

Se você expirar as mensagens (curto prazo), como ele vai lembrar disso? A solução não é desligar o TTL, mas sim mudar o tipo de memória.

Quando uma informação é muito importante para ser esquecida, nós a transferimos da Memória de Curto Prazo (Janela de Contexto) para a Memória de Longo Prazo (Banco de Dados Vetorial / RAG).
Assim, o agente "esquece" a conversa do dia a dia, mas quando você pedir uma receita, ele busca ativamente no banco de dados: "Opa, achei aqui no banco que esse usuário é alérgico a camarão", e injeta essa informação na janela de contexto apenas naquele momento exato.

Conclusão

Construir Agentes de IA escaláveis vai muito além de escolher o melhor prompt ou o LLM mais poderoso. Trata-se de engenharia de software tradicional aplicada a novas interfaces.

Esquecer de forma estratégica é o que mantém o seu agente rápido, barato e preciso. Na próxima vez que estiver codificando um loop de interação, pergunte-se: Qual é o tempo de vida ideal para esta informação?

E você, já teve algum susto com a fatura da OpenAI por causa de vazamento de contexto? Como você está gerenciando a memória dos seus agentes hoje? Conta aí nos comentários! 👇

Imagem Docker não é a mesma coisa que contêiner Docker

Felipe Cezar — Sun, 12 Apr 2026 12:48:53 +0000

Muita gente confunde esses dois conceitos no começo, mas eles são coisas diferentes.

A ideia mais simples de entender

Pensa assim:

Imagem é o molde pronto
Contêiner é esse molde em execução

O que é uma imagem?

A imagem Docker é o resultado do docker build.

Ela já vem com tudo empacotado:

Python
bibliotecas
teu código
configurações

Mas ela, sozinha, não executa nada.

É como se fosse um sistema já preparado para rodar, mas ainda parado.

O que é um contêiner?

O contêiner é a imagem rodando de verdade.

Quando tu executa:

docker compose up

o Docker pega a imagem e cria uma instância ativa dela.

Aí sim a aplicação fica viva:

Uvicorn sobe
a porta 8000 começa a escutar
as requisições passam a ser processadas

Uma analogia boa: classe e objeto

Se tu vem de programação, essa comparação ajuda muito:

Imagem = classe
Contêiner = objeto

Ou seja, a imagem é o molde, e o contêiner é a instância criada a partir dele.

E assim como uma classe pode gerar vários objetos, uma imagem também pode gerar vários contêineres.

Como ver isso no terminal

Tu consegue observar essa diferença com dois comandos:

docker images
docker ps -a

O que cada um mostra?

docker images mostra as imagens salvas no disco
docker ps -a mostra os contêineres criados

Um exemplo prático

No teu caso, aconteceu algo assim:

docker images mostrou 1 imagem
docker ps -a mostrou 0 contêineres

Isso significa que o molde ainda existe, mas nenhuma instância está rodando no momento.

Provavelmente porque tu executou:

docker compose down

Então por que o próximo build fica mais rápido?

Porque a imagem continua salva no disco mesmo sem nenhum contêiner rodando.

Por isso o Docker pode reaproveitar camadas já existentes, em vez de baixar e reconstruir tudo do zero.

Resumindo

Imagem Docker

É o pacote pronto, criado no build.

Contêiner Docker

É esse pacote em execução.

Conclusão

No fim, a diferença é essa:

imagem é o pacote; contêiner é o processo rodando.

Quando tu entende isso, várias coisas no Docker começam a fazer muito mais sentido.

Type Hints no Python, FastAPI e o Espectro entre Tipagem Estática e Dinâmica

Felipe Cezar — Sat, 11 Apr 2026 21:07:50 +0000

Você sabia que Python, uma linguagem dinamicamente tipada, permite que você escreva código que parece estaticamente tipado? E que um dos frameworks mais populares do ecossistema Python, o FastAPI, se apoia totalmente nisso?

Vamos por partes.

O que são Type Hints?

Type hints (ou "dicas de tipo") são anotações que você adiciona ao código Python para indicar qual tipo de dado uma variável, parâmetro ou retorno de função deveria ter. Eles foram introduzidos na PEP 484 (Python 3.5+).

Sem type hints:

def somar(a, b):
    return a + b

Com type hints:

def somar(a: int, b: int) -> int:
    return a + b

O detalhe crucial: o Python NÃO impede você de passar uma string ali. Ele continua sendo dinamicamente tipado. Os type hints são apenas anotações. Quem realmente usa essas anotações são ferramentas externas como o mypy, o Pyright e, claro, o FastAPI.

E o que o FastAPI faz com isso?

O FastAPI é um framework web moderno para construir APIs em Python. Ele usa os type hints para:

Validar automaticamente os dados de entrada
Serializar/deserializar JSON
Gerar documentação interativa (Swagger UI) sem esforço

Exemplo prático:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Usuario(BaseModel):
    nome: str
    idade: int
    email: str

@app.post("/usuarios")
def criar_usuario(usuario: Usuario):
    return {"msg": f"Bem-vindo, {usuario.nome}!"}

Só com essas anotações de tipo, o FastAPI já sabe que se alguém mandar {"nome": "Felipe", "idade": "abc", "email": "f@x.com"}, ele vai rejeitar a request porque "abc" não é um int. E a documentação interativa já aparece pronta em /docs. Tudo isso vem de graça pelos type hints.

O grande tema: tipagem dinâmica vs. estática

As linguagens de programação costumam ser classificadas assim:

Estaticamente tipadas: os tipos são verificados em tempo de compilação. Se tem erro de tipo, o código nem compila. Exemplos: Java, C, C++, Go, Rust.
Dinamicamente tipadas: os tipos só são verificados em tempo de execução. Você pode atribuir qualquer valor a qualquer variável. Exemplos: Python, JavaScript, Ruby, PHP.

Mas essa fronteira ficou muito borrada nos últimos anos. E é aí que fica interessante.

Linguagens estáticas que "parecem" dinâmicas

Java com var (Java 10+):

var nome = "Felipe";       // o compilador infere que é String
var lista = List.of(1, 2); // infere List<Integer>

Continua estático! O tipo é inferido em compilação, você só não precisa escrever ele explicitamente. Se tentar fazer nome = 42 depois, não compila.

Kotlin com val/var:

val idade = 25  // Int inferido
val nome = "Felipe"  // String inferido

Go com :=:

nome := "Felipe"  // string inferido
idade := 25       // int inferido

C++ com auto:

auto x = 3.14;  // double inferido
auto s = std::string("hello");

Em todos esses casos, a tipagem continua sendo estática e rígida. O compilador resolve o tipo sozinho por inferência. Mas visualmente, o código parece tão "solto" quanto Python.

Linguagens dinâmicas que "parecem" estáticas

Python com type hints:

def buscar(id: int) -> dict[str, str]:
    ...

JavaScript com TypeScript:

let nome: string = "Felipe";
let idade: number = 25;

function somar(a: number, b: number): number {
    return a + b;
}

TypeScript é o exemplo mais radical disso. Ele adiciona uma camada inteira de tipagem estática sobre o JavaScript, mas no final tudo é compilado de volta para JS puro (sem tipos).

PHP com type declarations (PHP 7+):

function somar(int $a, int $b): int {
    return $a + $b;
}

Ruby com Sorbet/RBS:

# typed: strict
sig {params(nome: String, idade: Integer).returns(String)}
def saudacao(nome, idade)
  "Olá, #{nome}! Você tem #{idade} anos."
end

O espectro, não a caixa

A verdade é que "dinâmica vs. estática" não é mais uma classificação binária. É um espectro:

Lado estático puro: C, Rust, Haskell
Estático com inferência forte: Kotlin, Go, Swift
Tipagem gradual: TypeScript, Python + mypy, PHP 7+
Dinâmico com anotações opcionais: Ruby + Sorbet
Lado dinâmico puro: JavaScript vanilla, Lua

O movimento é claro: linguagens dinâmicas estão adotando mecanismos de tipagem estática, e linguagens estáticas estão ficando mais ergonômicas com inferência de tipos. Ambos os lados estão caminhando para o meio.

E o Python, com seus type hints, está no coração desse movimento. Frameworks como o FastAPI provam que essas anotações não são só "decoração". Elas alimentam validação, documentação e tooling real.

Se você trabalha com Python e ainda não usa type hints, vale muito a pena começar. Seu editor vai te agradecer, seu time vai te agradecer, e o FastAPI vai fazer mágica com eles.

A Pegadinha do Auto-Incremento: Como o SERIAL do PostgreSQL se compara a outros SGBDs

Felipe Cezar — Thu, 05 Mar 2026 15:25:01 +0000

Se você está começando na área de dados ou backend, é quase certeza que você aprendeu a criar tabelas em um banco de dados específico (como o MySQL) e, quando foi tentar rodar o mesmo script em outro banco (como o PostgreSQL), tomou um belo erro de sintaxe na cara.

A maior vítima dessa "salada de frutas" entre os Sistemas Gerenciadores de Banco de Dados (SGBDs) é a famosa coluna de ID automático.

Neste artigo, vamos desmistificar como o PostgreSQL lida com isso através do SERIAL e como essa mesma funcionalidade é escrita nos outros gigantes do mercado.

🐘 O que é o SERIAL no PostgreSQL?

A primeira coisa que você precisa saber e que "buga" a cabeça de muita gente: o SERIAL não é um tipo de dado real. Ele é uma "pseudo-tipagem", um atalho de conveniência que o Postgres criou para facilitar a nossa vida. Quando você define uma coluna como SERIAL, o banco de dados faz três coisas automaticamente por debaixo dos panos:

Cria um objeto gerador de números chamado SEQUENCE.
Define o tipo real da sua coluna como INTEGER.
Adiciona uma restrição DEFAULT na coluna, dizendo que, se você não enviar um ID no seu INSERT, o banco deve puxar o próximo número gerado pela sequência (1, 2, 3...).

Exemplo na prática (PostgreSQL):

CREATE TABLE funcionario (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(255),
    data_admissao DATE
);

🌍 Como o Auto-Incremento funciona em outros Bancos?

O SQL tem um padrão universal (ANSI), mas na hora de criar IDs automáticos, cada fabricante decidiu seguir o seu próprio caminho. Olha só como a mesma tabela acima seria criada nos concorrentes:

1. MySQL e MariaDB (O Clássico)

Se você vem do PHP ou dos tutoriais clássicos de web, esse é o que você conhece. O MySQL usa a palavra-chave explícita AUTO_INCREMENT atrelada ao tipo inteiro.

CREATE TABLE funcionario (
    id INT AUTO_INCREMENT PRIMARY KEY,
    nome VARCHAR(255),
    data_admissao DATE
);

2. SQL Server / T-SQL (O Jeito Microsoft)

A Microsoft resolveu chamar essa funcionalidade de "Identidade". Você usa a palavra IDENTITY e pode até definir onde começa e de quanto em quanto o número pula. Exemplo: IDENTITY(1,1) significa "comece no 1 e pule de 1 em 1".

CREATE TABLE funcionario (
    id INT IDENTITY(1,1) PRIMARY KEY,
    nome VARCHAR(255),
    data_admissao DATE
);

3. Oracle (A Evolução)

O Oracle historicamente dava mais trabalho. Você precisava criar uma SEQUENCE na mão e depois criar uma TRIGGER para disparar essa sequência antes de cada inserção.
Felizmente, a partir da versão 12c, eles introduziram o GENERATED ALWAYS AS IDENTITY, que deixou tudo mais parecido com os outros SGBDs:

CREATE TABLE funcionario (
    id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    nome VARCHAR2(255),
    data_admissao DATE
);

4. SQLite (O Simples e Local)

No banco queridinho dos aplicativos mobile, o simples fato de você declarar uma coluna como INTEGER PRIMARY KEY já faz com que ela seja auto-incremental por padrão. Mas, se quiser ser muito explícito, pode usar a palavra AUTOINCREMENT.

CREATE TABLE funcionario (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    nome TEXT,
    data_admissao DATE
);

🎯 Conclusão

Entender que o SQL tem suas "gírias locais" dependendo do SGBD é o que separa um iniciante de um desenvolvedor mais maduro (e salva a sua pele em provas de concurso ou testes técnicos de vagas).

Na próxima vez que o seu script falhar ao trocar de banco de dados, lembre-se de checar como aquele sistema específico prefere chamar as coisas!

E você, qual dessas sintaxes está mais acostumado a usar no seu dia a dia? Conta aí nos comentários! 👇

DEV Community: Felipe Cezar

Palantir: a empresa que transforma dados em decisões operacionais

Entendendo o `if __name__ == "__main__"` no Python de forma prática

Primeiro: main.py não é a mesma coisa que "__main__"

O que é __name__?

Exemplo 1: executando o arquivo diretamente

Arquivo: calculadora.py

Exemplo 2: importando o arquivo

Arquivo: app.py

Então o que significa if __name__ == "__main__"?

Arquivo: calculadora.py

Agora usando calculadora.py em outro arquivo

Arquivo: app.py

Dentro de app.py

Dentro de calculadora.py

Arquivo: calculadora.py

O que acontece se eu não usar isso?

Arquivo: relatorio.py

Arquivo: app.py

Por que isso é um problema?

A versão correta

Arquivo: relatorio.py

Arquivo: app.py

E a função main()?

Arquivo: main.py

Arquivo: main.py

Arquivo: main.py

Então por que usar if __name__ == "__main__"?

Regra prática

Arquivo: operacoes.py

Arquivo: operacoes.py

Resumo direto

Arquivo: app.py

Arquivo: calculadora.py

Arquivo: app.py

Conclusão

Arquivo: main.py

O que é um RTOS e qual a diferença para um sistema operacional comum?

O problema que um RTOS resolve

Sistema operacional comum vs RTOS

A diferença principal

“Tempo real” não significa instantâneo

Exemplo prático: drone

Tasks: a unidade básica de trabalho

Escalonamento

Interrupções

Hard real-time e soft real-time

Hard real-time

Soft real-time

FreeRTOS como exemplo

Por que não usar Linux em tudo?

Exemplo prático: sensor IoT

Exemplo prático: equipamento médico

Quando usar um RTOS?

Quando não usar um RTOS?

Resumo direto

GPL vs DSL: entendendo a diferença entre linguagens de propósito geral e linguagens específicas

1. GPL: General-Purpose Language

2. DSL: Domain-Specific Language

3. Comparando GPL e DSL

4. Exemplo usando desenvolvimento web

5. DSLs geralmente são mais limitadas?

6. Algumas DSLs podem ter lógica?

7. Framework não é linguagem

8. Servidor também não é linguagem

9. Resumo final

Web Crawling e Web Scraping

1. Web Crawling (Rastreamento Web)

A Definição

O Exemplo Clássico

No seu projeto de Artigos Científicos

Ferramentas

2. Web Scraping (Raspagem de Dados)

A Definição

O Exemplo Clássico

No seu projeto de Artigos Científicos

Ferramentas

O Confronto Direto: Resumo

A Situação Real: Unindo os Dois no Fluxo ELT

A Fase Crawler

Entendendo o `if name == "main"` no Python de forma prática

Primeiro: `main.py` não é a mesma coisa que `"main"`

O que é `name`?

Arquivo: `calculadora.py`

Arquivo: `app.py`

Então o que significa `if name == "main"`?

Arquivo: `calculadora.py`

Agora usando `calculadora.py` em outro arquivo

Arquivo: `app.py`

Dentro de `app.py`

Dentro de `calculadora.py`

Arquivo: `calculadora.py`

Arquivo: `relatorio.py`

Arquivo: `app.py`

Arquivo: `relatorio.py`

Arquivo: `app.py`

E a função `main()`?

Arquivo: `main.py`

Arquivo: `main.py`

Arquivo: `main.py`

Então por que usar `if name == "main"`?

Arquivo: `operacoes.py`

Arquivo: `operacoes.py`

Arquivo: `app.py`

Arquivo: `calculadora.py`

Arquivo: `app.py`

Arquivo: `main.py`

O Casamento Perfeito: `Falsy` + `if not`