Notes RSS feed

• Lazy loading: ~500 KB a menos no bundle inicial

  17/06/26, 12:00

  No dashboard do Ponto Glass, duas abas carregavam bibliotecas pesadas: exportação de PDF (~300 KB com jspdf) e exportação de Excel (~200 KB com xlsx). Ambas eram importadas no topo do arquivo — mesmo que o usuário nunca abrisse essas abas.

  A solução foi substituir por next/dynamic com { ssr: false }:

  const RelatoriosTab = dynamic(() => import("./RelatoriosTab"), { ssr: false });
  const RegistrosTab = dynamic(() => import("./RegistrosTab"), { ssr: false });

  Resultado: aproximadamente 500 KB a menos no bundle inicial. O único custo é um estado de loading na primeira abertura de cada aba — aceitável para funcionalidades de uso eventual.

  O critério para aplicar lazy loading: o componente precisa satisfazer duas condições simultaneamente — (1) conter bibliotecas ou lógica pesada e (2) não estar visível no carregamento inicial. Lazy loading em componentes leves ou acima da dobra piora a experiência sem nenhum ganho de performance mensurável.

• Row Level Security: isolamento de dados no nível do banco

  10/06/26, 08:00

  A abordagem mais comum para isolar dados de múltiplos tenants é validar o perfil do usuário na camada de aplicação antes de cada query. O problema: qualquer falha nessa lógica pode expor dados de outras empresas.

  Row Level Security (RLS) move esse controle para dentro do PostgreSQL. Com RLS ativado, toda query é automaticamente filtrada pelas políticas definidas no banco — independentemente de como foi construída na aplicação.

  -- retorna apenas registros da empresa do usuário autenticado
  CREATE POLICY "users see own company"
  ON registros_ponto
  FOR SELECT
  USING (empresa_id = (auth.jwt() ->> 'empresa_id')::uuid);

  O Supabase expõe o JWT do usuário autenticado diretamente nas políticas via auth.jwt(), tornando o padrão direto de implementar. O benefício central: o isolamento funciona por padrão — via aplicação, Supabase Studio ou qualquer cliente SQL.

  No Ponto Glass, RLS foi o mecanismo de separação entre empresas: cada empresa enxerga apenas seus próprios trabalhadores, registros e relatórios, sem nenhuma lógica adicional na camada de aplicação para garantir isso.

  Regra prática: se uma tabela contém dados de múltiplos tenants, RLS é mais seguro e mais confiável do que isolamento implementado no servidor.

• Window functions: analítica sem colapsar as linhas

  04/06/26, 07:00

  Window functions resolvem uma limitação central do GROUP BY: a perda do detalhe das linhas originais após a agregação.

  Com RANK(), ROW_NUMBER(), LAG() e LEAD(), os cálculos analíticos são executados sobre o conjunto de linhas original — sem colapsá-lo. É possível manter o nível de detalhe e acessar o valor calculado na mesma linha.

  Um exemplo concreto: calcular o crescimento mês a mês de receita. Com LAG(), é uma expressão na cláusula SELECT:

  receita - LAG(receita) OVER (ORDER BY mes) AS variacao_mom

  Sem window functions, o mesmo resultado exigiria uma CTE para materializar o mês anterior e um join posterior — mais código e mais pontos de falha.

  Casos de uso mais comuns:

  • Ranking de clientes ou produtos por métrica — RANK, DENSE_RANK
  • Numeração sequencial de registros por grupo — ROW_NUMBER
  • Comparação com período anterior ou seguinte — LAG, LEAD
  • Totais acumulados — SUM ... OVER (ORDER BY ...)

• SQL ou Python: critérios práticos para a escolha certa

  01/06/26, 14:30

  A questão “SQL ou Python?” é recorrente, mas a resposta depende menos de preferência e mais do contexto do problema.

  Prefira SQL quando:

  • Os dados estão no banco e a transformação pode ser executada na própria fonte — joins, agregações e filtros em grande volume são otimizados pelo banco por padrão
  • O resultado precisa ser compartilhado com outras ferramentas que consomem diretamente do banco

  Prefira Python quando:

  • A lógica exige expressividade que SQL não oferece nativamente — machine learning, manipulação de texto complexa, integração com APIs externas
  • O pipeline combina múltiplas fontes heterogêneas
  • A etapa final é uma visualização, relatório automatizado ou modelo preditivo

  Na prática, o fluxo mais eficiente é composto: SQL para extração e agregação na fonte, Python para análise, modelagem e visualização. Tentar fazer tudo em uma única ferramenta normalmente gera atrito desnecessário.

  O critério decisivo: qual das duas resolve esse problema específico com menor overhead?

• pandas .query() para filtros mais expressivos em DataFrames

  28/05/26, 09:00

  A sintaxe de filtragem booleana padrão do pandas funciona, mas se torna verbosa rapidamente com múltiplas condições. O método .query() oferece uma alternativa mais expressiva:

  # filtragem booleana padrão
  df[(df["status"] == "completed") & (df["total"] > 100)]
  
  # com .query()
  df.query("status == 'completed' and total > 100")

  Para referenciar variáveis do escopo externo, use o prefixo @:

  threshold = 100
  df.query("total > @threshold")

  .query() é especialmente vantajoso em notebooks, onde a legibilidade do código tem peso tão grande quanto o resultado em si. Para filtragens que envolvem índices, operações vetorizadas ou chamadas de método, a sintaxe booleana padrão ainda é a escolha mais adequada.

• 80% do tempo em dados é limpeza — e está certo

  20/05/26, 12:00

  Limpeza de dados frequentemente é tratada como overhead — a parte operacional antes da “análise de verdade”. Na prática, é exatamente o contrário.

  A etapa de limpeza é a análise. É o momento em que se entende o que os dados representam de fato: onde estão as lacunas, quais campos foram mal registrados, quais valores fogem do padrão esperado. Pular essa etapa é chegar a conclusões incorretas apresentadas com gráficos bem elaborados.

  Na análise do Airbnb em Barcelona, os preços incluíam outliers extremos — listagens com €1 e €9.999 na mesma coluna. Se a média tivesse sido calculada diretamente sobre os dados brutos, o resultado não teria nenhuma aderência ao mercado real.

  A regra prática: dado sujo com análise elaborada produz insight incorreto. Dado limpo com análise simples produz decisão correta.