A Amazon anunciou que, a partir de 20 de maio, dispositivos Kindle mais antigos deixarão de permitir a compra e o download de livros diretamente pela Kindle Store. A mudança afeta todos os modelos lançados e vendidos até 2012.

Os usuários ainda poderão acessar e ler os livros que já estiverem armazenados nesses dispositivos, porém não será mais possível baixar novos conteúdos. Além disso, caso o aparelho seja restaurado para as configurações de fábrica, não será mais possível realizar login em uma conta da Amazon.

Esta é a primeira vez que a empresa descontinua completamente o suporte a modelos antigos da linha Kindle. Entre os dispositivos impactados estão:

• Kindle de 1ª e 2ª geração
• Kindle DX e DX Graphite
• Kindle Keyboard
• Kindle 4
• Kindle Touch
• Kindle 5
• Kindle Paperwhite de 1ª geração
• Tablets Kindle Fire das gerações de 2011 e 2012

A empresa automobilística Škoda apresentou uma campainha de bicicleta capaz de enganar algoritmos de fones de ouvido com cancelamento ativo de ruído.

Esses fones funcionam captando sons externos por meio de microfones e gerando ondas sonoras inversas para anulá-los, o que reduz a percepção do ambiente ao redor. Como consequência, pedestres podem deixar de ouvir alertas importantes, incluindo campainhas tradicionais de bicicleta, o que aumenta o risco de acidentes.

Para contornar essa limitação, a Škoda desenvolveu a campainha DuoBell, uma solução totalmente analógica e mecânica que emite som em uma faixa entre 750 e 780 Hz, capaz de atravessar os filtros desses fones. O dispositivo também conta com um ressonador adicional ajustado para uma frequência mais alta, ampliando a eficácia do sinal sonoro. Além disso, um mecanismo de martelo produz batidas rápidas e irregulares, gerando ondas sonoras que os algoritmos de cancelamento não conseguem processar com rapidez suficiente para suprimir.

Em testes, pedestres utilizando fones com cancelamento ativo ganharam até 22 metros adicionais de distância e 5 segundos extras de tempo de reação quando a DuoBell foi acionada.

Inicialmente, a tecnologia está disponível apenas em Londres, no Reino Unido, mas a Škoda planeja expandi-la globalmente.

Como qualquer pessoa normal, quando eu precisava gerar um QR Code, eu fazia o óbvio:

abria o Google e digitava: gerador de qrcode.

Eu só queria resolver meu problema em 5 minutos. Rápido. Simples. Sem dor.

Mas aí começa o inferno:

• Site lento
• “Crie sua conta para continuar”
• “Teste grátis por 7 dias”
• Marca d’água no QR
• Pede cartão pra baixar um PNG

Tudo isso… pra gerar um quadradinho preto.

Passei tanta raiva que desisti e fui direto no ChatGPT. Em segundos, resolvido.

Dias depois, me caiu a ficha:
isso não deveria ser difícil assim.

Então eu fiz o meu próprio gerador.

Foi exatamente essa frustração que me motivou a criar algo do jeito que deveria ser desde o início.

Um gerador de QR Code que:

• não pede login
• não pede cadastro
• não pede e-mail
• não tem marca d’água
• gera na hora
• baixa direto

Simples. Rápido. Funcional.

Do jeito que sempre deveria ter sido.

Se você já passou por essa mesma raiva, isso aqui é pra você:
https://quickeasy.tools/pt/tools/qr-code-generator

Quero muito o seu feedback.
O formulário de feedback do site está com problema por enquanto, então se puder, me escreva por aqui mesmo caso sinta falta de alguma funcionalidade ou encontre algum bug.

Olá, pessoal do TabNews.

Me chamo Yan e sou estudante do 6º ano de Engenharia de Computação na UFGD (Universidade Federal da Grande Dourados). Em janeiro deste ano, retornei ao Brasil após um período de intercâmbio no departamento de Engenharia de Sistemas da Universidade de Wakayama, no Japão.

Essa experiência de vivenciar dois mundos acadêmicos e tecnológicos tão distintos me trouxe reflexões profundas. Hoje, quero compartilhar com vocês as principais diferenças que observei entre a educação de engenharia no Brasil e no Japão, e o que podemos aprender com o estilo japonês.

1. A Cultura do "Kenkyushitsu" (Laboratório de Pesquisa)

No Brasil, é comum termos matérias até o final do curso e, paralelamente, fazermos um TCC ou uma Iniciação Científica. No Japão, o sistema é diferente.

Lá, existe a cultura do Kenkyushitsu (研究室). Nos últimos anos da graduação, o aluno é "adotado" por um laboratório e passa a viver aquele ambiente. Você ganha sua própria mesa no laboratório e sua rotina passa a ser quase inteiramente dedicada à pesquisa, lado a lado com mestrandos e doutorandos. Essa imersão cria um foco absurdo e um senso de comunidade e responsabilidade com o projeto muito forte. Foi nesse ambiente, por exemplo, que pude me aprofundar no conceito de "Natureza Digital" (Digital Nature), que hoje é o tema do meu TCC no Brasil.

2. O Foco Extremo na Base e no Hardware

No Brasil, vejo muitos estudantes (eu incluso, em vários momentos) com pressa para aprender o framework do momento para entrar logo no mercado de trabalho.

No Japão, a abordagem é muito mais voltada para a fundação. Mesmo em cursos focados em software, há uma carga pesadíssima em eletrônica, arquitetura de computadores, linguagens de baixo nível e matemática. A filosofia é: se você entende perfeitamente como o hardware se comporta (do Arduino aos processadores complexos), você consegue aprender qualquer framework de software rapidamente e com muito mais qualidade.

3. "Monozukuri": A Arte de Fazer Bem Feito

Existe um termo japonês chamado Monozukuri (ものづくり), que pode ser traduzido como a "arte de fabricar coisas". Isso se reflete diretamente no código e nos projetos.

Enquanto no Brasil temos o famoso "jogo de cintura" para resolver problemas rápidos (o que é uma grande qualidade nossa), no Japão o foco está no processo, na documentação minuciosa e em testes exaustivos antes de qualquer implementação. A tolerância a falhas na etapa de planejamento é baixíssima. É um processo mais lento no início, mas que gera sistemas extremamente robustos no longo prazo.

Conclusão: Unindo o Melhor dos Dois Mundos

Acredito que o engenheiro de computação brasileiro tem uma criatividade e uma capacidade de adaptação que são raras no mundo. No entanto, se conseguirmos aliar essa nossa agilidade com o rigor técnico, o foco na base e o respeito ao processo que os japoneses têm, nos tornaremos profissionais imbatíveis.

Gostaria de saber de vocês: como enxergam a nossa formação aqui no Brasil em relação a esses pontos? Alguém aqui já teve experiências trabalhando com equipes japonesas ou asiáticas?

Vou adorar ler os comentários e trocar ideias com vocês!

Quando eu era criança, eu já queria entender como a tecnologia funcionava de verdade.

Não era só usar — era abrir, fuçar, testar, quebrar e descobrir como as coisas eram feitas.

Hoje, olhando pra trás, percebo que estou me tornando exatamente aquilo que eu imaginava naquela época: alguém que entende (ou pelo menos tenta entender) como tudo funciona por baixo dos panos.

E foi daí que nasceu meu blog.

👉 https://wesleydmscn.com/

Ele não é um curso.
Não é uma documentação.
E definitivamente não é conteúdo genérico.

É mais como um caderno aberto.

Um lugar onde eu registro o que estou aprendendo — sobre programação, tecnologia, ciência da computação… e até retrogaming.

Sim, retrogaming também 🎮

Porque pra mim, entender tecnologia também passa por entender jogos clássicos, como eles funcionavam e o que tinha por trás daquilo tudo.

Alguns exemplos do que você vai encontrar lá:

• criar uma API estilo Bit.ly com Node.js puro
• conceitos mais profundos de TypeScript (Effective TS)
• React na prática
• programação de jogos
• e até coisas como mecânicas de jogos do PS1 (tipo Resident Evil)

Tudo sem a pretensão de ser perfeito — só útil.

Se você curte aprender entendendo de verdade (e não só copiando código), talvez faça sentido pra você.

🚀 https://wesleydmscn.com/

Quais informações vocês não conseguem encontrar fácil sobre seu condomínio? Quais sao as maiores dores que voce passa hoje no codnominio e na gestao ao ter contato com sindico?

Estou fazendo essas perguntas pois estou criando uma aplicacao para condominios e nada melhor que perguntar pra pessoas reais.

Meus 2 cents,

Conhecer por dentro a "caixa preta" ajuda bastante a planejar como usar melhor uma IA/LLM, entendendo como ela chega a certos resultados.

Fiz um vídeo para mostrar alguns pontos de como as coisas por debaixo do capô, e outras questões sobre o seu funcionamento.

• CAPÍTULO 2: ABRINDO A CAIXA PRETA

Abro com um exemplo de "teste de turing" bastante simples mas didático (ainda que polêmico), perguntando a 2 LLMs comerciais (chatGPT e Gemini):

"Preciso lavar meu carro, e o lava-jato fica a 50 metros da minha casa. É melhor ir a pé ou de carro ?"

O chatGPT analisou a questão como um dilema filosófico ou de estilo de vida, ignorando a premissa física óbvia:

Para lavar o carro, o objeto "carro" precisa ser levado fisicamente até lá.

O Gemini demonstrou um entendimento superior, mas ainda assim tratou a questão trivial com uma complexidade desnecessária e gastando uma linha de raciocínio imensa.

O argumento a favor da IA/LLM é que ela "chegou ao resultado certo" nos dois testes.

Porém, o que importa não é apenas o resultado, mas o que ele significa no mundo físico (e quais as premissas que foram assumidas para este significado).

NOTA: Por serem longas para um post, as respostas completas dos chatbots estão no capítulo 2 do livro.

Uma resposta humana coerente seria curta:

"Para lavar o carro, você precisa levá-lo até lá. Se não quiser dirigir, verifique se eles têm serviço de leva-e-traz".

A diferença é sutil, mas vital: o humano entende que o carro é o foco obrigatório da missão; a IA/LLM entende apenas que "carro", "pé" e "50 metros" são tokens que precisam ser avaliados quanto ao seu peso estatístico e relação com outros tokens para gerar uma resposta fluida (mas destituída de relação com o mundo físico).

LEMBRANDO: A IA/LLM não é "pior" que o humano; ela possui um raciocínio diferente, baseado em ângulos estatísticos e probabilidades de tokens.

Conclusão

Por isso, seja usando uma IA/LLM como ferramenta em questão da nossa vida cotidiana (p.ex. atendendo uma fila de Suporte/ URA/ Whatsapp/ etc), ou no planejamento e construção de um aplicativo é importante lembrar que a IA/LLM NÃO SABE a implicação das decisões no mundo real:

• Cabe a você, o desenvolvedor, fornecer este "ancoramento" na realidade que a IA/LLM não possui.

Saúde e Sucesso !

A CIA utilizou uma tecnologia inédita chamada “Ghost Murmur” para localizar e resgatar um aviador americano abatido no sul do Irã.

O nome “Murmur” faz referência ao termo clínico usado para descrever o ritmo cardíaco, enquanto “Ghost” remete à ideia de localizar alguém desaparecido.

A ferramenta emprega magnetometria quântica de longo alcance para identificar a “impressão eletromagnética” de um batimento cardíaco humano, conseguindo isolar esse sinal em meio ao ruído de fundo. O sistema conseguiu detectar os sinais vitais do aviador, especialmente no momento em que ele deixou um esconderijo para transmitir um sinal.

Esta foi a primeira vez que a tecnologia foi utilizada em uma operação real. Sua capacidade é comparada a “ouvir uma voz em um estádio”, e apresenta melhor desempenho em ambientes com baixa interferência eletromagnética, como regiões desérticas.

Criei um SaaS que permite configurar agentes PicoClaw com apenas um clique, facilitando a vida de quem tem dificuldade em mexer com terminais ou VPS.
O PicoClaw é uma variante do OpenClaw escrita em Go, o que o torna extremamente leve, sendo capaz de rodar em dispositivos com apenas 10 MB de RAM.

No meu painel, o processo é muito simples: o usuário faz o login, escolhe um plano, define o nome do bot e insere sua chave de API do Google.

O sistema então se comunica com a minha VPS, faz o deploy via Docker e gera um acesso seguro através de um IP e um token.

Apesar de leve, ele mantém as funções do OpenClaw, permitindo conexões com Telegram, Discord e até sugestões de integração com WhatsApp.

O maior desafio técnico foi fazer a plataforma Base 44 conversar com a VPS de forma consistente para clonar as imagens sem erros.

Atualmente, cada nó da minha VPS suporta até 10 agentes, mas pretendo expandir anexando novos nós no futuro.

https://picoclawone.com

Seguindo a série sobre deep links em Flutter sem pacote. Desta vez: iOS nativo.

A lógica é a mesma do Android. As APIs são completamente diferentes.

No Post 3 implementei:

• Info.plist com CFBundleURLTypes para registrar o custom scheme (fitconnect://)
• Runner.entitlements com Associated Domains para Universal Links
• AppDelegate.swift com:
  • FlutterMethodChannel → link no cold start
  • FlutterEventChannel → stream com app aberto
  • open url → custom scheme
  • continue userActivity → Universal Links

// Custom schemeoverride func application(_ app: UIApplication,    open url: URL,    options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {    handleDeepLink(url: url, isInitial: false)    return super.application(app, open: url, options: options)}// Universal Linksoverride func application(_ application: UIApplication,    continue userActivity: NSUserActivity,    restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,          let url = userActivity.webpageURL else { return false }    handleDeepLink(url: url, isInitial: false)    return true}

Coisas que quebram fácil

• testar Universal Links colando no Safari (não funciona — use iMessage ou Mail)
• esquecer o prefixo applinks: no Associated Domains
• apple-app-site-association não configurado no servidor (Post 5)
• link chegando duas vezes no cold start — lastProcessedLink resolve

Fonte (post completo no Medium)

https://medium.com/@crdornelles/deep-links-no-ios-implementa%C3%A7%C3%A3o-nativa-com-swift-flutter-parte-3-d37569fd0a15

Se alguém já teve Universal Link abrindo no Safari em vez do app mesmo com tudo configurado — conta como resolveu. Esse é o problema mais comum nessa etapa.

## O problema que ninguém admiteVocê instala pacotes npm sem pensar. Expõe APIs sem versionamento. Valida dados só no frontend. Contribui com open source sem entender a governança do projeto.São lacunas silenciosas. Não quebram nada hoje. Mas amanhã, destroem produção.Este post cobre cinco lacunas reais que encontro repetidamente em projetos JavaScript profissionais. Cada uma com diagnóstico, ferramenta e código funcional.Vamos direto.## Lacuna 1: Segurança de dependências npmA maioria dos devs roda `npm install` e nunca mais olha para o que entrou no `node_modules`. Isso é um convite para supply chain attacks.O incidente do `event-stream` em 2018 provou isso. Um pacote com milhões de downloads semanais foi comprometido. O atacante injetou código malicioso que roubava bitcoins.### Diagnóstico rápidoRode isso agora no seu projeto:```bashnpm audit

Provavelmente você verá vulnerabilidades. Mas npm audit sozinho não basta. Ele só checa o registry público. Não detecta typosquatting, pacotes abandonados ou maintainers comprometidos.

Ferramentas que realmente cobrem a lacuna

Instale o socket.dev CLI para análise profunda:

npm install -g @socketsecurity/cli

Agora rode a análise no seu projeto:

socket scan ./package.json

Para automatizar no CI, adicione ao seu package.json:

{  "scripts": {    "security:audit": "npm audit --audit-level=high",    "security:scan": "socket scan ./package.json",    "security:check": "npm run security:audit && npm run security:scan"  }}

Lockfile — sua primeira linha de defesa

Nunca ignore o package-lock.json. Ele garante builds reproduzíveis. Em CI, use sempre:

npm ci

O npm ci respeita o lockfile literalmente. O npm install pode alterá-lo. Essa diferença sutil já causou bugs em produção que levaram dias para diagnosticar.

Política de dependências com .npmrc

Crie um .npmrc na raiz do projeto:

audit=truefund=falsesave-exact=trueengine-strict=true

O save-exact=true é crucial. Ele trava a versão exata no package.json, eliminando surpresas de minor/patch updates automáticos.

Lacuna 2: APIs sem versionamento nem contrato

Você cria uma rota /api/users, deploya, e três meses depois precisa mudar o formato de resposta. Quebra todos os clientes. Clássico.

Versionamento por URL — o jeito pragmático

// server.jsimport express from 'express';const app = express();// v1 — contrato originalapp.get('/api/v1/users', (req, res) => {  res.json({    users: [      { id: 1, name: 'Ana', email: 'ana@email.com' }    ]  });});// v2 — novo formato com paginaçãoapp.get('/api/v2/users', (req, res) => {  res.json({    data: [      { id: 1, fullName: 'Ana Silva', contact: { email: 'ana@email.com' } }    ],    meta: { page: 1, total: 1, perPage: 20 }  });});app.listen(3000, () => console.log('API rodando na porta 3000'));

Contrato com Zod — validação em runtime

Essa é a lacuna mais perigosa. TypeScript valida em compile time. Mas dados de API chegam em runtime. TypeScript não existe em runtime.

Instale o Zod:

npm install zod

Agora crie contratos reais:

// contracts/user.jsimport { z } from 'zod';export const CreateUserSchema = z.object({  name: z.string().min(2).max(100),  email: z.string().email(),  age: z.number().int().min(18).max(120).optional(),});export const UserResponseSchema = z.object({  id: z.number(),  name: z.string(),  email: z.string().email(),  createdAt: z.string().datetime(),});// Tipos derivados automaticamenteexport type CreateUserInput = z.infer<typeof CreateUserSchema>;export type UserResponse = z.infer<typeof UserResponseSchema>;

Use no middleware do Express:

// middleware/validate.jsexport function validate(schema) {  return (req, res, next) => {    const result = schema.safeParse(req.body);    if (!result.success) {      return res.st---Leia o artigo completo em [https://vivodecodigo.com.br/backend/lacunas-criticas-javascript-api-npm-opensource-webdev](https://vivodecodigo.com.br/backend/lacunas-criticas-javascript-api-npm-opensource-webdev)

Pesquisadores apresentaram uma técnica para transformar resíduos da produção de bourbon, um tipo de uísque, em materiais voltados ao armazenamento de energia, com potencial aplicação em veículos elétricos e redes elétricas.

Atualmente, esses resíduos, formados por grãos usados e água, em um volume de 6 a 10 vezes maior que cada barril produzido, precisam passar por um processo de secagem antes de serem reutilizados como ração ou fertilizante, o que demanda tempo ou métodos caros de aquecimento.

A proposta elimina essa etapa ao converter diretamente o material úmido em um pó de carbono, que pode ser refinado em carbono ativado, adequado para supercapacitores, e em carbono duro, com estrutura semelhante ao grafite e eficiente no armazenamento de íons como lítio e sódio, utilizados em baterias.

Nos testes, os pesquisadores desenvolveram supercapacitores com densidade de energia de até 48 watt-hora por quilograma, valor comparável ao de dispositivos comerciais, além de um supercapacitor híbrido de íon-lítio capaz de armazenar até 25 vezes mais energia do que modelos convencionais.

A equipe acredita que a solução pode contribuir para atender à crescente demanda por materiais para baterias, especialmente diante da expansão da indústria de veículos elétricos.

A polícia de Londres investiga um ex-funcionário da Meta suspeito de ter baixado cerca de 30 mil imagens privadas de usuários do Facebook. O indivíduo teria desenvolvido um programa capaz de acessar fotos pessoais na plataforma ao contornar mecanismos de verificação de segurança.

A empresa afirma que identificou a violação há mais de um ano e realizou a demissão imediata do funcionário. O suspeito foi preso em novembro de 2025, liberado sob fiança e deverá se apresentar novamente à polícia em maio. A Meta também informa que notificou os usuários afetados e que, desde então, reforçou seus sistemas de segurança.

No post anterior eu expliquei como construí a Bely — um launcher para Windows com 70+ ferramentas usando Tauri 2 e React. Agora quero contar sobre uma decisão que tomei essa semana: abrir o app para plugins externos.

Por que plugins

A Bely já tem muita coisa built-in. Mas eu sei que em algum momento vou precisar que outras pessoas consigam estender o app sem depender de mim pra cada feature nova. Integração com API interna de empresa, lookup de pacote npm, ferramentas de nicho — são coisas que fazem sentido pra alguém mas não pra todo mundo.

Ao invés de esperar essa demanda aparecer, decidi construir a infraestrutura agora enquanto o projeto ainda é pequeno e eu consigo iterar rápido. Se der errado, pelo menos aprendi. Se der certo, o app já está pronto pra escalar.

O problema do iframe sandbox

A primeira decisão foi: como isolar o código de terceiros? Eu não posso simplesmente executar JS arbitrário no contexto do meu app — isso daria acesso ao filesystem, clipboard, e todas as APIs do Tauri.

A solução foi usar iframes com sandbox="allow-scripts". O plugin roda num documento HTML separado, carregado via blob URL, sem acesso ao DOM pai. Toda comunicação passa por postMessage.

Parece simples, mas tem uma cascata de problemas:

1. O iframe não herda o tema. O plugin renderiza num contexto CSS completamente isolado. Tive que coletar todas as CSS variables do tema glass (--glass-bg, --glass-text, --accent, etc — são mais de 40) e injetar como inline style no HTML do iframe. Se o usuário troca o tema, preciso mandar uma mensagem pro iframe atualizar.

2. O iframe rouba o foco da janela. Esse foi o bug mais irritante. No Windows, quando o acrylic blur está ativo e o usuário clica dentro do iframe (num input de busca do plugin, por exemplo), o window do documento pai dispara um evento blur. O app interpretava isso como "janela perdeu foco" e trocava o background de translúcido para opaco — matando o efeito glass.

A correção foi trocar o listener de window.blur/focus do DOM pela API nativa do Tauri (getCurrentWindow().onFocusChanged()), que detecta foco no nível do sistema operacional. O iframe está na mesma janela do OS, então o foco continua "ativo" mesmo quando o usuário interage com o plugin.

3. CORS mata tudo. Os plugins precisam fazer fetch pra APIs externas (npm registry, GitHub, etc). Mas o fetch roda no contexto do host app que está em http://tauri.localhost. A maioria das APIs bloqueia por CORS.

A solução foi criar um proxy no Rust. O plugin manda uma mensagem { type: "api-call", method: "fetch", args: [url, options] }, o host repassa pro backend Rust que faz o request via reqwest (sem restrição de CORS) e devolve o resultado.

O SDK

Não dá pra esperar que alguém escreva HTML cru com postMessage. Criei um SDK (@usebely/sdk) que abstrai tudo:

import { mount, List, useFetch } from "@usebely/sdk";function App() {  const [query, setQuery] = useState("");  const { data, loading } = useFetch(    query.length >= 2      ? `https://registry.npmjs.org/-/v1/search?text=${query}`      : null  );  return (    <List searchBarPlaceholder="Buscar pacotes..." onSearchChange={setQuery} isLoading={loading}>      {data?.objects?.map((obj) => (        <List.Item          key={obj.package.name}          title={obj.package.name}          subtitle={obj.package.description}        />      ))}    </List>  );}mount(<App />);

O SDK fornece componentes que já seguem o design system glass da Bely: List, Detail, Form, Grid, Action, ActionPanel. Todos usam as CSS variables injetadas, então o plugin automaticamente respeita o tema do usuário.

O useFetch tem debounce de 300ms e roteia pelo proxy Rust. O mount() cuida de montar o React, receber mensagens do host, e notificar quando o plugin está pronto.

Permissões

Cada plugin declara no manifest quais APIs precisa:

{  "permissions": ["fetch", "clipboard.write"]}

Se o plugin tenta chamar algo que não declarou, o host bloqueia. As permissões disponíveis são: fetch, clipboard.read, clipboard.write, fs.read, fs.write, system.info. O usuário vê as permissões antes de instalar.

A Plugin Store

O fluxo:

1. Dev builda o plugin e abre Plugin Store > Enviar na Bely
2. Preenche metadados (nome, ícone, categoria) e seleciona a pasta do plugin
3. O app cria um .tar.gz com o código completo (incluindo source pra review) e faz upload pro S3
4. Plugin fica pendente até ser aprovado no painel admin
5. Quando aprovado, aparece na store pra instalar

Versionamento: versão aprovada não pode ser editada — precisa submeter uma nova. Versões pendentes podem ser editadas antes da aprovação. Bundle tem limite de 5MB.

No app, quando um plugin instalado tem versão nova na store, o card mostra "Atualizar" em vez de "Instalado". O detail view mostra o changelog de cada versão.

O que aprendi

Isolamento é caro. O iframe sandbox resolve segurança mas cria uma barreira de comunicação. Cada feature que funciona "de graça" no app principal (tema, foco, fetch, clipboard) precisa de uma ponte explícita pro plugin.

O SDK é o produto. Se for difícil criar um plugin, ninguém vai criar. Investir tempo nos componentes e na DX valeu mais do que qualquer feature da store.

Review manual é o certo por enquanto. Hoje eu baixo o bundle, leio o source, testo. Não escala, mas com zero plugins de terceiros no momento, é melhor garantir qualidade do que automatizar algo que ninguém está usando.

Glass theme em iframes é sofrimento. A quantidade de edge cases entre transparência, composição de rgba, e comportamento diferente entre Windows 10 e 11 é absurda. Se eu fosse começar de novo, talvez considerasse web components no mesmo documento ao invés de iframes.

Status

O sistema de plugins está na v1.26.0. O SDK é funcional e já tem um plugin de exemplo (NPM Lookup) na store. A documentação está em https://bely.my/docs/plugins

A Bely está em whitelist beta: https://bely.my

Feedback técnico é bem-vindo — especialmente de quem já lidou com plugin systems ou iframe sandboxing.

Se liga nessa situação que rolou comigo há algum tempo... dia tranquilo até que a pipeline caiu "do nada" (sempre assim né? xD). O erro apontava para a VM, mas a causa real estava escondida em três mudanças de uma PR que ninguém tinha percebido.

O problema

Um dev me pingou: "Tá dando erro estranho na pipe, olha aí?" Parei o que eu estava fazendo e fui investigar.

Acessei o build e de primeira já verifiquei que falhou na etapa de instalação do Angular. Isso já me deu o palpite de que podia ser um problema na VM, pois essa pipeline usava um agente self-hosted (para contexto, nessa situação estamos falando de Azure DevOps e Bitbucket).

A investigação

Abri a task de instalação do Angular e a primeira mensagem que vi foi: ENOTEMPTY: directory not empty, rename '.../cli' -> '.../cli-Xuqet0PR'

Exatamente desse jeito, inclusive vou deixar o output aqui para ficar mais fácil de entender:

2000-00-00T13:00:57Z [command] npm install -g @angular/cli@XX.X.12000-00-00T13:01:15Z npm error code ENOTEMPTY2000-00-00T13:01:15Z npm error syscall rename2000-00-00T13:01:15Z npm error path   .../node_modules/@angular/cli2000-00-00T13:01:15Z npm error dest   .../node_modules/@angular/.cli-Xuqet0PR2000-00-00T13:01:15Z npm error errno  -392000-00-00T13:01:15Z npm error ENOTEMPTY: directory not empty, rename '.../cli' -> '.../cli-Xuqet0PR'2000-00-00T13:01:16Z ##[error]Error: Npm failed with return code: 217

De primeira dá para notar que o npm tentou renomear uma pasta e não conseguiu... como eu não sabia a fundo como funcionava o processo de instalação, dei uma pesquisada rápida e descobri que ao instalar o Angular, o npm tenta renomear o diretório atual (cli) para um nome temporário (.cli-Xuqet0PR) e se der certo esse rename, ele faz a instalação do Angular na pasta /cli, esse processo é basicamente para liberar o caminho no diretório antes de escrever a nova versão. O problema é que de alguma forma já existia um temporário lá e já estava com conteúdo, então o rename falhou, o processo morreu, o build foi junto.

Agora a grande pergunta não era o que quebrou. Era o porquê esse diretório temporário estava ali.

Aqui começa a investigação de verdade... Fui na lista de builds no Azure DevOps, procurei o último lote de builds com sucesso e identifiquei o momento exato em que as falhas começaram. Abri o build correspondente, acessei a PR em andamento e encontrei uma alteração no YAML da pipeline: o dev tinha removido a etapa de instalação do Angular.

# trecho removido da pipeline pelo dev- task: Npm@1  inputs:    command: 'custom'    customCommand: 'install -g @angular/cli@XX.X.1'  displayName: 'Install Angular CLI'

Esse tipo de mudança é estranho, mas como o dev é novato e está começando, eu relevei e entendi que talvez ele não soube como resolver o problema do ENOTEMPTY, e usou IA para resolver mas não passou contexto suficiente.

Antes de continuar investigando, preciso liberar o fluxo...

Pipeline parada é prioridade máxima. Como DevOps, minha função é acelerar o ciclo de entrega do time, e build travado é o oposto disso.

Dei um change request na PR, chamei o dev no privado para avisar sobre a alteração do YAML e comuniquei ao time no grupo que eu já estava verificando o problema com a pipeline. Com isso feito, ativei a VPN e acessei a VM via SSH.

Tava lá. O diretório temporário abandonado, exatamente como o erro dizia.

Como eu falei anteriormente, o fluxo do npm é renomear a pasta /cli para um nome temporário e processar o pacote. Se o processo é interrompido no meio, o diretório temporário fica para trás. Na próxima execução, quando o npm tenta renomear de novo, encontra um diretório não vazio e explode com ENOTEMPTY.

Para resolver eu simplesmente apaguei as pastas...

Rodei a pipeline de novo e passou. Problema resolvido, avisei o time no grupo que a pipe estava liberada. Agora preciso entender a causa raiz.

Quem interrompeu o processo?

Um princípio que carrego na minha carreira é: nada acontece do nada.

De cara, minha dedução foi que o problema estava na alteração do YAML que o novato fez. Mas fui checar o histórico da PR e notei que ele só removeu a instalação do Angular no terceiro commit. O erro já estava quebrando a pipeline antes disso.

Fui ver nos logs do agente na VM (aqui aprendi na marra algo que eu não tinha prestado atenção antes: a VM estava em UTC e eu estava em UTC-3) e os builds que via no Azure DevOps como falho às 08:53 correspondia a 11:53 na VM. Isso importa na hora de correlacionar logs, demorei uns minutos para lembrar disso xD

$ cat /home/vm-admin/myagent/_diag/Agent_*.log | grep "Running job"[2000-00-00 01:00:39Z] Running job: Build Frontend[2000-00-00 01:03:25Z] Running job: Build Frontend[2000-00-00 01:05:58Z] Running job: Build Frontend[2000-00-00 02:00:20Z] Running job: Job[2000-00-00 02:10:37Z] Running job: Job[2000-00-00 02:20:45Z] Running job: Job[2000-00-00 11:49:37Z] Running job: Job  ← suspeito[2000-00-00 11:50:35Z] Running job: Job  ← suspeito[2000-00-00 11:53:12Z] Running job: Job  ← falhou

Ao ler o log, fui por eliminação... como eu sabia que tinha pipe que rodou de madrugada por schedule e o build que eu procurava era das 11:53, sobraram dois jobs que não apareciam na interface do Azure DevOps. Foi só nesse momento que notei o número do build que havia falhado: #20000000.3. Tava na minha cara o tempo todo. O sufixo (3) já indicava que era a terceira execução do dia. Não vi antes... mas acontece xD.

Lendo os logs dos Workers

Bom, agora que eu sei que tem dois builds que foram apagados e não aparecem na interface, e tenho informações de horário, vou até os logs de Workers. Lá é um arquivo por build, e o melhor, com o horário de início em UTC no próprio nome do arquivo.

$ ls /home/vm-admin/myagent/_diag/Worker_20000000-114938-utc.logWorker_20000000-115038-utc.log

Achei esses dois logs, e os minutos batem com o log que analisei anteriormente... Só podiam ser esses.

Log era enorme, então copiei, joguei para a IA e perguntei: "o que aconteceu com esse build? Foi deletado, cancelado, crashou?"

A IA respondeu:

Pipeline:     [empresa] - Dashboard (Staging)Build:        20000000.1 | Motivo: PullRequestResultado:    CanceledMomento:      durante o passo Cache npmConsequência: todos os passos seguintes foram skippedNesse log não aparece quem cancelou.O log mostra apenas que o agente recebeu um sinal de cancelamento.

Opa, agora sei que os dois builds foram cancelados. Não foi crash, não foi a VM. Receberam um sinal externo. Mas de quem?

O culpado

Builds cancelados podem não aparecer na interface gráfica do Azure DevOps, mas da API não tem como, ela expõe isso. Montei a URL com ajuda de IA, já autenticado no portal, e o JSON retornou:

"deletedBy": "Microsoft.VisualStudio.Services.TFS","deletedReason": "The build was manually deleted.","pr.autoCancel": "true"

Aí o culpado... Não foi o dev. Não foi ninguém do time. Foi o próprio Azure DevOps, pelo pr.autoCancel que cancela automaticamente qualquer build em andamento toda vez que a PR é atualizada.

Fui até a PR no Bitbucket para tirar a prova real, e reconstruí a sequência, olha que dahora:

1. Dev abriu a PR → build 20000000.1 inicia
2. Dev marcou como DRAFT → auto-cancel derruba o build .1 → build 20000000.2 inicia
3. Dev editou o título da PR → auto-cancel derruba o build .2 durante o npm install → .cli-Xuqet0PR fica incompleto na VM → build 20000000.3 inicia → ENOTEMPTY → todos os builds seguintes quebram.

Insight: Olha que massa, eu realmente não sabia que editar o título de uma PR também disparava um novo build. E na verdade qualquer atualização na PR com um build em andamento aciona o pr.autoCancel. Se o cancelamento ocorre no meio de um processo com estado em disco, como o npm install, o rastro fica na VM e quebra todos os builds seguintes até alguém limpar manualmente.

Caraca, fiquei de cara quando entendi o problema pela raiz... e qual foi o aprendizado? Só crie a PR quando ela estiver 100% pronta. xD

Obviamente que esse problema não podemos colocar na conta do novato... nem eu sabia que podia dar problema... mas uma boa prática é você abrir a PR tendo a certeza que ela está pronta... ou já abrir ela como draft.

E é isso, basicamente essas 3 mudanças rápidas que o dev fez (literalmente uma em seguida da outra) foi matando os builds com o autocancel e na última alteração deu ruim.

Bom, isso ocorreu há um tempo atrás... mas conhecimento nunca ocupa espaço, então ficou de aprendizado haha

Já tinha visto esse B.O antes? Conta aí

Ficou em aberto

Por que o npm não faz cleanup ao receber o sinal de cancelamento? Dependendo de como o sinal é entregue e em que ponto do rename o processo estava, o cleanup pode não acontecer. Não investiguei a fundo.

O pr.autoCancel tem configuração granular? Não verifiquei se é possível desativar por pipeline específica ou se é global.

Dá para tornar o step idempotente? Uma limpeza antes do npm install -g eliminaria o problema independentemente de cancelamentos futuros:

- script: |    rm -rf $(node_modules_path)/@angular/cli    rm -rf $(node_modules_path)/@angular/.cli-*  displayName: 'Clean Angular'

Não implementei ainda. Não sei se gera efeito colateral em builds paralelos no mesmo agente.

Referências

• Azure DevOps REST API - Builds
• Azure Pipelines - PR Triggers e autoCancel
• npm CLI - npm install

Vinicius Aguilar — DevOps Engineer

Fala pessoal,

Sou o Germán, dev solo de Buenos Aires. Nos últimos meses tenho trabalhado full-time com agentes de IA (principalmente Claude Code e Gemini CLI) e percebi que faltava uma ferramenta decente pra gerenciar essa bagunça toda de terminais.

O problema é simples: quando você roda 3-4 agentes de IA ao mesmo tempo, cada um num terminal diferente, fica impossível acompanhar qual precisa de input, qual tá processando, qual já terminou. Alt-tab entre 6 janelas o dia todo não é produtividade, é sofrimento.

O que eu construí

Patapim — uma IDE de terminal (não é editor de código) feita especificamente pra quem trabalha com agentes de IA.

As features principais:

Grid de 9 terminais — Tudo na mesma tela, cada terminal com borda colorida: vermelho = agente trabalhando, verde = precisa do seu input. Parece bobagem mas isso mudou meu workflow completamente. Antes eu ficava checando terminal por terminal.

Ditado por voz local — Usa Whisper rodando local, nada sai da sua máquina. Eu uso porque já tive problemas com eye floaters e ficar digitando o dia todo é complicado. Mas qualquer um que prefere falar ao invés de digitar comandos longos vai curtir.

Acesso remoto pelo celular — Gera um QR code, abre um túnel via Cloudflare, e você controla seus terminais do celular. Eu uso quando preciso sair do computador mas tenho agentes rodando.

Browser embutido como MCP server — O Claude Code consegue controlar um browser real direto do terminal. Pra automação e testes é muito útil.

Stack técnico (pra quem curte)

• Electron + xterm.js + node-pty
• WebSocket pra comunicação em tempo real entre terminais
• Cloudflare Workers pro túnel remoto
• Whisper.cpp compilado local pra ditado
• O browser se registra como MCP server automaticamente

Preço

Tier grátis com tudo que importa (9 terminais, 3 projetos, 30 min ditado/dia). Pro a 6.99/mês ou 29.99 lifetime pra quem quer projetos ilimitados e ditado ilimitado.

Por que tô postando aqui

Eu sei que TabNews valoriza conteúdo técnico, não propaganda. Não vim aqui vender nada — vim compartilhar porque genuinamente acho que quem tá usando Claude Code ou Gemini CLI no dia-a-dia vai entender o problema que isso resolve.

Se alguém quiser testar, posso dar licença Pro gratuita. Sem compromisso nenhum, só quero feedback.

Site: patapim.ai

Aceito perguntas técnicas, críticas, sugestões. Se alguém quiser que eu faça um post mais deep-dive sobre alguma parte da arquitetura (tipo como integrei o Whisper, ou como funciona o MCP server), me fala que eu escrevo.

Hoje, quero apresentar um projeto empolgante que venho desenvolvendo: LLM-MAR (Multi Agent Reasoning). Este é um CLI compacto e poderoso que permite criar agentes de LLM, fazer debates entre eles, responder perguntas e construir workflows complexos.

O que é LLM-MAR?

LLM-MAR é uma ferramenta de linha de comando que simplifica o trabalho com Large Language Models (LLMs) em cenários multi-agente. A sigla MAR significa "Multi Agent Reasoning" - raciocínio multi-agente. A ideia é permitir que diferentes agentes especializados colaborem, debatam e cheguem a conclusões mais robustas.

Principais Recursos

• Criação de Agentes: Defina agentes com personalidades, objetivos e instruções específicas
• Debates Inteligentes: Faça agentes debaterem tópicos complexos
• Workflows Flexíveis: Construa pipelines de processamento com múltiplos agentes
• Integração OpenAI: Suporte nativo para modelos GPT via LangChain
• Formato YAML: Configurações fáceis de versionar e compartilhar

Por que Multi-Agent Reasoning?

Os LLMs são incrivelmente poderosos, mas têm limitações quando trabalham isoladamente. O raciocínio multi-agente oferece várias vantagens:

1. Perspectivas Diversas: Diferentes agentes podem abordar problemas de ângulos únicos
2. Validação Cruzada: Agentes podem verificar e refinar as respostas uns dos outros
3. Especialização: Cada agente pode se focar em aspectos específicos do problema
4. Robustez: Reduz alucinações através de consenso e debate

Como Começar

Instalação

npm install -g llm-mar

Configuração

Configure sua chave da OpenAI:

export OPENAI_API_KEY=sua_chave_aqui

Primeiro Agente

Crie um agente simples:

llm-mar create agent meu_agente \  --model gpt-4 \  --goal "Responder perguntas de forma clara e precisa" \  --role "Assistente Técnico" \  --system-prompt "Você é um assistente técnico especializado em desenvolvimento de software." \  --instructions "Pense passo a passo,Seja conciso mas completo" \  --output text

Executando o Agente

llm-mar run default/meu_agente.yaml --input "Como implementar autenticação JWT em Node.js?"

Casos de Uso Avançados

Debates Filosóficos

Imagine um debate entre agentes representando diferentes filósofos:

• Sócrates: Focado em questionamento e maiêutica
• Aristóteles: Ênfase em lógica e observação empírica
• Platão: Perspectiva idealista e formas puras

Análise de Código

Agentes especializados em diferentes aspectos:

• Segurança: Foca em vulnerabilidades
• Performance: Otimização e eficiência
• Manutenibilidade: Legibilidade e padrões

Tomada de Decisão Empresarial

• Analista Financeiro: Foca em ROI e custos
• Especialista em UX: Considera experiência do usuário
• Desenvolvedor: Avalia viabilidade técnica

Arquitetura Técnica

O LLM-MAR é construído com tecnologias modernas:

• Node.js: Runtime JavaScript eficiente
• Commander.js: Para interface de linha de comando robusta
• LangChain: Framework para aplicações LLM
• YAML: Formato de configuração legível por humanos
• Zod: Validação de esquemas TypeScript

Benefícios para Desenvolvedores

1. Prototyping Rápido: Crie agentes complexos em minutos
2. Versionamento: Configurações em YAML facilitam controle de versão
3. Extensibilidade: Arquitetura modular permite novos tipos de agentes
4. Integração: Funciona com qualquer LLM suportado pelo LangChain
5. Open Source: Código disponível para contribuição e auditoria

Futuro do Projeto

Estamos trabalhando em várias melhorias:

• Suporte a mais provedores: Anthropic, Google, local LLMs
• Integração com ferramentas: GitHub Actions, CI/CD
• Templates pré-configurados: Agentes para casos comuns
• Avaliação automática: Métricas de qualidade das respostas

Contribuição

O projeto é open source, se você tem ideias para melhorar o LLM-MAR:

1. Abra uma issue no GitHub
2. Faça um fork e envie um PR

Este post é baseado no artigo de Andrej Karpathy publicado em abril de 2026, onde ele propõe um padrão inovador para gerenciar conhecimento pessoal com o auxílio de LLMs.

O Problema com RAG Tradicional

A maioria das pessoas que usa LLMs com documentos segue o mesmo padrão: você envia arquivos, o modelo recupera fragmentos relevantes e gera uma resposta. É o que chamamos de RAG (Retrieval-Augmented Generation).

Funciona. Mas tem um problema fundamental que Karpathy identifica com precisão:

"Nada é construído. O LLM redescobre conhecimento do zero a cada pergunta."

Toda vez que você faz uma pergunta, o modelo parte da estaca zero. Não há acúmulo. Não há síntese persistente. Não há memória real — apenas recuperação.

A Proposta: Um Wiki Mantido por LLMs

A ideia central do LLM Wiki é simples, mas poderosa: em vez de usar o LLM apenas para recuperar documentos brutos, você o usa para construir e manter um wiki persistente.

Esse wiki é uma coleção estruturada e interligada de arquivos Markdown que fica entre você e suas fontes originais. Quando você adiciona um novo documento, o LLM não apenas o indexa — ele:

1. Lê o documento inteiro
2. Extrai as informações-chave
3. Integra-as ao wiki existente
4. Atualiza páginas de entidades relacionadas
5. Revisa sínteses já existentes
6. Sinaliza contradições entre fontes

A diferença crucial: o wiki é um artefato persistente e composto. As referências cruzadas já existem. As contradições já foram identificadas. O trabalho intelectual de conexão não precisa ser refeito a cada consulta.

As Três Camadas da Arquitetura

O padrão é elegantemente dividido em três camadas:

1. Fontes Brutas

Seus documentos originais — artigos, papers, notas, dados. São imutáveis. O LLM lê, mas nunca altera.

2. O Wiki

Um diretório de arquivos Markdown gerados e mantidos pelo LLM. Contém resumos, páginas de entidades, sínteses temáticas, e conexões entre conceitos.

3. O Schema (CLAUDE.md)

Um documento de configuração que instrui o LLM sobre a estrutura do seu wiki, as convenções de nomenclatura, e os fluxos de trabalho esperados. É aqui que você define as regras do jogo.

As Três Operações Principais

Ingest

Quando uma nova fonte entra, o LLM a processa completamente: cria uma página de resumo, atualiza o índice, e modifica 10 a 15 páginas correlatas do wiki. O trabalho que levaria horas para um humano acontece em minutos.

Query

Ao fazer uma pergunta, o LLM busca páginas relevantes do wiki (não os documentos brutos), sintetiza uma resposta com citações, e pode opcionalmente arquivar os achados como novas páginas — fazendo o conhecimento crescer por exploração, não apenas por ingestão.

Lint

Uma verificação periódica de saúde do wiki: contradições entre fontes, claims desatualizados, páginas órfãs sem referências, lacunas de cobertura. Como um compilador, mas para conhecimento.

Arquivos Especiais

O padrão define dois arquivos de controle:

• index.md — catálogo orientado ao conteúdo, organizado por categoria. Sua visão geral de tudo que existe no wiki.
• log.md — registro cronológico e append-only de todas as operações. Permite auditar o que foi processado e quando.

Onde Usar

Karpathy sugere vários contextos práticos:

• Rastreamento pessoal — objetivos, saúde, psicologia, journaling estruturado
• Pesquisa aprofundada — mergulhos em tópicos complexos com síntese progressiva
• Leitura de livros — personagens, temas e conexões entre obras mantidos automaticamente
• Wikis de equipe — alimentados por transcrições de reuniões e documentos internos
• Análise competitiva — due diligence, benchmarking, monitoramento de mercado

Por Que Isso Importa

A ideia remete ao conceito de Memex de Vannevar Bush (1945) — uma máquina para estender a memória humana através de associações. A diferença é que, em 1945, manter essas associações seria trabalho humano intenso. Hoje, os LLMs resolvem exatamente essa parte.

Como Karpathy coloca:

"O LLM não se entedia, não esquece de atualizar referências cruzadas e toca 15 arquivos de uma vez."

O humano continua no papel que faz sentido: curar fontes e fazer as perguntas certas. O LLM executa o trabalho de síntese, arquivamento e manutenção de consistência.

Minha Leitura

O que me chama atenção nesse padrão é o compounding. Conhecimento que cresce por uso, não apenas por acumulação. Cada consulta bem respondida pode se tornar uma nova entrada no wiki. Cada nova fonte processada enriquece as conexões existentes.

É uma mudança de paradigma sobre o que significa "usar um LLM": de uma ferramenta de consulta pontual para um parceiro de curadoria intelectual contínua.

Se você trabalha com pesquisa, escrita, ou qualquer domínio onde o acúmulo de conhecimento importa, vale experimentar esse padrão.

Leia o artigo original de Andrej Karpathy no GitHub Gist.

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Construí audiência no instagram no último ano sem aparecer, tenho uma página de filosofia, focada em estoicismo, e já não é de hoje que penso nisso, mas agora tomei a decisão de botar pra frente.. quero construir apps pra minha audiência, testar, iterar... aproveitar a distribuição e a credibilidade que construí até aqui.

Obviamente não quero construir mais um habit tracker, app de meditação, ou diário, como outros mihões que já existem.. Caso alguém tenha alguma ideia que gostaria de compartilhar ou interesse em conversar sobre construirmos algo juntos, confere minha página e o meu email pra contato abaixo:

Minha página é a stoicus.filosofia.

E-mail para contato: stoicusfilosofia@gmail.com

A Microsoft anunciou que passará a forçar a atualização de dispositivos ainda em execução no Windows 11 24H2 para a versão mais recente, o 25H2. O suporte ao 24H2 será encerrado em 13 de outubro.

A distribuição obrigatória será direcionada especificamente a dispositivos com as edições Home e Pro do Windows 11 24H2. Máquinas gerenciadas por organizações ou departamentos de TI, por enquanto, não estão incluídas nesse processo.

A liberação será conduzida por um sistema de atualização inteligente baseado em aprendizado de máquina, responsável por determinar quando cada dispositivo está pronto para receber o update. No entanto, não foram divulgados detalhes sobre os critérios utilizados para essa decisão.

Usuários ainda poderão adiar a atualização por um período limitado, embora esse intervalo não tenha sido especificado. Também será possível iniciar o processo manualmente por meio do Windows Update.

Entre 1º de março de 2025 e 11 de março de 2026, grupos de ransomware divulgaram 7.655 reivindicações de vítimas em sites públicos de vazamento, anúncios nos quais afirmam ter invadido organizações e roubado seus dados. O volume equivale a uma média de cerca de 20 casos por dia, ou uma nova organização exposta a cada 71 minutos.

Os grupos com maior número de reivindicações no período foram Qilin, com 1.179 registros, Akira, com 706, e INC Ransom, com 415.

Em relação aos setores, o de manufatura lidera com 890 reivindicações, no qual interrupções operacionais tendem a aumentar a pressão pelo pagamento de resgates. Na sequência aparecem os setores de tecnologia, com 843, e saúde, com 537.

No recorte por países, os EUA concentram 3.101 reivindicações, seguidos por Alemanha, com 315, e Canadá, com 311. O Brasil aparece na 8ª posição, com 132 casos.

Os dados foram compilados a partir de publicações em sites de vazamento monitorados por rastreadores públicos de atividades de ransomware. As contagens não representam necessariamente invasões confirmadas, mas sim alegações feitas publicamente pelos próprios grupos criminosos.

A Anthropic anunciou o Project Glasswing, uma iniciativa que reúne empresas como AWS, Apple, CrowdStrike, Google, Linux Foundation, Microsoft e Nvidia com o objetivo de fortalecer a segurança dos softwares mais críticos do mundo.

O núcleo do projeto é o modelo Claude Mythos Preview, ainda não lançado, mas que, segundo a empresa, já apresenta um nível de capacidade capaz de superar a maioria dos humanos na identificação e exploração de vulnerabilidades.

Como parte da iniciativa, as empresas parceiras passarão a utilizar a tecnologia em suas operações de segurança defensiva. O acesso também foi ampliado para mais de 40 organizações responsáveis pelo desenvolvimento ou manutenção de infraestruturas críticas.

De acordo com a Anthropic, nas últimas semanas o Mythos Preview foi empregado na identificação de milhares de vulnerabilidades zero-day, muitas classificadas como críticas, abrangendo todos os principais sistemas operacionais e navegadores.

Entre os casos identificados estão uma vulnerabilidade de 27 anos no OpenBSD, que permitia derrubar remotamente qualquer máquina conectada ao sistema; uma falha de 16 anos no FFmpeg, localizada em um trecho de código amplamente testado sem que o problema fosse detectado; além de múltiplas vulnerabilidades no Linux kernel, que possibilitavam a escalada de privilégios de um usuário comum para controle total da máquina. Todas as falhas já foram corrigidas.

Ainda não há previsão para a disponibilização pública da tecnologia.

A Cloudflare anunciou o objetivo de implementar, até 2029, um modelo de segurança totalmente resistente a computadores quânticos.

A urgência aumentou após avanços recentes no setor, incluindo o desenvolvimento, pelo Google, de um algoritmo capaz de quebrar criptografia de curva elíptica, amplamente utilizada em conexões HTTPS, certificados digitais, aplicativos de mensagens com criptografia de ponta a ponta e criptomoedas.

Esses progressos indicam que o chamado “Q-Day”, momento em que computadores quânticos conseguirão comprometer os padrões atuais de criptografia, pode ocorrer por volta de 2030.

Desde 2022, a Cloudflare já adota criptografia pós-quântica em sites sob sua proteção como forma de mitigar ataques do tipo “coletar agora, descriptografar depois”, estratégia em que invasores interceptam e armazenam dados criptografados hoje para decifrá-los no futuro, quando dispuserem de tecnologia suficiente. Agora, o principal risco passa a ser a quebra de mecanismos de autenticação, o que pode permitir que agentes maliciosos se passem por sistemas legítimos ou forjem credenciais válidas.

A empresa afirma que pretende disponibilizar essas proteções de forma padrão e sem custo adicional assim que estiverem disponíveis no futuro.

Vou contar um problema que qualquer dev que cuida do próprio front já viveu: você abre o CSS de um projeto com seis meses, procura o gap entre dois componentes e encontra 12px num lugar, 14px em outro, 13px num terceiro. Ninguém sabe de onde vieram. Provavelmente de um "parece certo" feito em três momentos diferentes, com estados de espírito diferentes.

Isso tem nome: é decisão sem critério. E ela acumula.

Passei alguns meses construindo um sistema para resolver isso de forma que fosse auditável — onde qualquer token publicado tivesse uma cadeia de raciocínio rastreável. O resultado foi um framework de derivação matemática usando três constantes: a Razão Áurea (Φ), a Sequência de Fibonacci e o Ângulo Áureo (θ).

O artigo explica o método. Não é magia — é uma estrutura de decisão.

O problema que eu queria resolver

Decisões arbitrárias de espaçamento e tipografia não são apenas esteticamente incômodas. Elas criam dívida técnica de design: valores sem critério que nenhum novo membro do time consegue reconstituir, exceções que se acumulam sem registro, sistemas que funcionam parte por parte mas não comunicam unidade formal.

A primeira pergunta que me fiz foi: existe uma forma de derivar tokens a partir de um método reproduzível, que qualquer pessoa com acesso à documentação consiga reconstruir do zero?

A resposta foi usar matemática como estrutura de relações — não como garantia de beleza, mas como fonte de consistência.

Por que Fibonacci para espaçamento?

A Sequência de Fibonacci (1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...) tem uma propriedade útil para design: ela é aditiva com saltos crescentes. Isso produz uma escala que cobre bem o range de micro (2–8px) a macro (55–144px) sem exigir interpolação arbitrária.

A ideia é simples: você escolhe uma âncora — um step Fibonacci que vai corresponder a um valor em px que faz sentido ergonômico para o seu produto — e deriva o resto por proporção.

Exemplo com âncora F(9)=34 → 16px:

space(n) = F(n) × (16/34)F(8)=21  →  9.88px  → quantizado para 10pxF(9)=34  → 16.00px  ← âncoraF(10)=55 → 25.88px  → quantizado para 26pxF(11)=89 → 41.88px  → quantizado para 42px

O token publicado não é 9.88px — é 10px. A derivação fica documentada internamente; o CSS recebe valores limpos.

:root {  --space-10:  10px;  --space-16:  16px;   /* âncora F(9) */  --space-26:  26px;  --space-42:  42px;  --space-68:  68px;  --space-110: 110px;}

E os componentes nunca usam esses primitivos diretamente — usam tokens semânticos:

:root {  --space-inset-md:  var(--space-10);  /* padding de botão */  --space-gap-lg:    var(--space-16);  /* gap entre grupos */  --space-section-sm: var(--space-42); /* entre seções */}.button {  padding: var(--space-inset-md); /* correto */  /* padding: var(--space-10);   ← nunca isso */}

Quando você muda a âncora, reconstrói a escala inteira. Quando você muda a semântica, refatora os tokens sem mexer no CSS dos componentes.

Por que Φ para tipografia?

A Razão Áurea (Φ ≈ 1.618) gera progressões geométricas com razão constante e auto-similar. Em tipografia, isso significa que cada step tem a mesma relação com os adjacentes.

Mas — e esse "mas" é importante — Φ não é bala de prata. Para dashboards e interfaces densas, uma escala com Φ produz headings gigantes:

Um H1 de 67px convive bem num hero de landing page. Num dashboard onde heading e corpo dividem a mesma tela, é inapropriado. A escolha da razão é editorial — o framework oferece um menu de razões com nomes baseados em intervalos musicais:

Em tipografia fluida com clamp(), os limites mínimo e máximo de cada step derivam das duas âncoras — base mobile e base desktop:

/* Quarta Perfeita, BASE mobile=14px → desktop=18px */--text-body: clamp(0.875rem, 0.696rem + 0.536vi, 1.125rem);--text-h2:   clamp(1.556rem, 1.238rem + 0.952vi, 2.000rem);--text-h1:   clamp(2.075rem, 1.651rem + 1.270vi, 2.669rem);

O Golden Angle para distribuição de cores

O Ângulo Áureo (θ ≈ 137.508°) distribui matizes no círculo cromático de forma que cada nova cor adicionada ocupa o ponto de maior separação angular das já existentes. É uma propriedade matematicamente verificável, não apenas estética.

hue(n) = (H₀ + n × 137.508°) mod 360°Com H₀ = 220° (azul-marca):  accent-1: 220.0°  (azul)  accent-2: 357.5°  (vermelho-rosa)  accent-3: 135.0°  (verde)  accent-4: 272.5°  (roxo)  accent-5:  50.0°  (âmbar)

Para os tokens de cor, o framework usa oklch — um espaço de cor com luminosidade perceptualmente uniforme. hsl(60, 100%, 50%) (amarelo) parece muito mais claro que hsl(240, 100%, 50%) (azul) mesmo com L=50%. Em oklch, o canal L corresponde à luminância percebida pelo olho humano.

Um aviso importante, que descobri na prática: nem toda combinação de L, C e H em oklch cabe no gamut sRGB. Antes de publicar tokens em produção, valide clipping de gamut usando oklch.com. Copiar os valores sem verificar pode gerar comportamentos inconsistentes entre navegadores.

O que a matemática não resolve — e o documento não esconde

Esse é talvez o ponto mais importante, e o que diferencia esse framework de um manifesto:

Proporções matematicamente perfeitas frequentemente precisam de compensação óptica. Um círculo precisa ser ligeiramente maior que um quadrado de mesma área para parecer do mesmo tamanho. Texto centralizado geometricamente num botão parece baixo demais — o olho humano não lê o centro matemático como centro visual.

Harmonia proporcional não garante boa UX. Um componente com espaçamentos perfeitos pode ter hierarquia confusa, affordance inadequada, ergonomia insuficiente.

Phi não é lei perceptiva universal. Estudos sobre preferência pela proporção áurea têm resultados mistos e metodologias contestadas. O que Φ oferece é consistência de razão — não preferência universal garantida.

O framework foi escrito para deixar isso explícito. A matemática organiza o espaço de decisão. Dentro dele, julgamento editorial, contexto de produto e pesquisa de usuário continuam determinantes.

A arquitetura de governança

O que diferencia esse projeto de uma tabela de valores é a camada de governança. Cada token tem:

• derivação documentada (de qual fórmula veio)
• erro de quantização registrado
• mapeamento semântico explícito
• critério para abrir exceção
• sinal para recalibrar a âncora

Por exemplo, se mais de 25% dos componentes precisam de correção manual de line-height, o problema não está nos componentes — está na âncora de leading. Recalibrar é a resposta certa; acumular exceções é dívida técnica disfarçada de flexibilidade.

O documento define cinco níveis de precedência quando há conflito:

1 — Acessibilidade (absoluta — contraste WCAG, reduced motion)2 — Ergonomia (tamanhos mínimos de toque, legibilidade)3 — Percepção óptica (compensações necessárias)4 — Coerência semântica (a intenção do token deve ser preservada)5 — Derivação matemática (menor precedência em conflito)

A matemática tem a menor precedência. Ela é ponto de partida, não ponto de chegada obrigatório.

O resultado em números

O sistema derivado para um SaaS com base 16px, Quarta Perfeita (1.333) e T=150ms de animação:

/* Escala de espaçamento completa */--space-2: 2px;  --space-4: 4px;   --space-6: 6px;--space-10: 10px; --space-16: 16px; --space-26: 26px;--space-42: 42px; --space-68: 68px; --space-110: 110px;/* Durações de animação derivadas de Φ */--duration-instant: 57ms;   /* 150 × Φ⁻² */--duration-fast:    93ms;   /* 150 × Φ⁻¹ */--duration-normal:  150ms;  /* âncora */--duration-slow:    243ms;  /* 150 × Φ¹ *//* Easing baseado em Φ⁻¹ = 0.618 */--ease-harmonic: cubic-bezier(0.618, 0.000, 0.382, 1.000);--ease-out-phi:  cubic-bezier(0.000, 0.000, 0.382, 1.000);

Onde encontrar o documento completo

O framework está documentado num arquivo .md de aproximadamente 2.000 linhas, com:

• Derivação matemática de cada subsistema (espaçamento, tipografia, cor, animação, grid, border radius, elevação)
• Tabelas de referência por contexto (SaaS, marketing, editorial, mobile, dashboard)
• Critérios de validação por camada
• Anti-padrões documentados
• Processo de recalibração
• Métricas de sucesso para medir se o sistema está funcionando em produção

Se houver interesse, o repositorio é: https://github.com/MolinariBR/NebulaDesign. Aceito perguntas nos comentários — especialmente sobre os trade-offs de escolha de razão tipográfica e os casos onde o framework tem aplicabilidade limitada.

Uma observação final: esse framework é um método, não uma biblioteca. Os tokens são instanciações de uma configuração específica de âncoras. O valor real não está nos números — está na cadeia de decisão que eles tornam auditável.

Sempre pensei em código como poesia, mas nunca encontrei uma maneira visual de mostrar.

Eu AMO áudio (sou dj nas horas vagas) e espaço.

Enquanto estava trabalhando em refazer meu site pessoal, resolvi dar um jeito de mostrar essa beleza que eu vejo.

Assim surgiu o Code Planets - suas contribuções do github como planetas e música.

Você também pode criar o seu, clica no planeta ali dentro e informa o seu user.
Compartilhando pelo link, as configurações de filtros do áudio e do planeta vão junto <3

Valeu galera!

Fala, pessoal!

Recentemente resolvi criar uma nova ferramenta utilitária para o meu blog e acabei esbarrando num desafio de regra de negócio muito interessante:
- calcular uma rescisão de contrato CLT.

Para quem já precisou ler a legislação trabalhista, sabe que ela é cheia de particularidades. Para a lógica de programação, o maior desafio não está nas operações matemáticas em si, mas sim no controle rigoroso das frações de tempo.

O pulo do gato está na famosa "regra dos 15 dias". Uma fração igual ou superior a 15 dias de trabalho no mês quebrado dá ao empregado o direito a 1/12 extra de férias e de 13º salário. Além disso, existe o cálculo do aviso prévio proporcional, que exige o acréscimo de 3 dias para cada ano completo trabalhado limitado a 90 dias.

Dessa forma decidi estruturar um algoritmo em Python. Separei as regras trabalhistas em funções modulares. Por exemplo, a lógica de cálculo de férias proporcionais ficou com esse formato para lidar com os meses fechados e o mês "quebrado":

def calcular_ferias_proporcionais(adm, dem, salario):    anos = dem.year - adm.year    meses = dem.month - adm.month    dias = dem.day - adm.day    if dias < 0:        meses -= 1    if meses < 0:        anos -= 1        meses += 12    meses_trabalhados = (anos * 12) + meses    meses_ferias = meses_trabalhados % 12    if dias >= 15:        meses_ferias += 1    meses_ferias = min(meses_ferias, 12)    base_ferias = (salario / 12) * meses_ferias    um_terco = base_ferias / 3    return base_ferias + um_terco

Outro ponto crítico foi criar condicionais pois se o motivo da rescisão for justa causa, o código aborta imediatamente a soma de 13º e férias proporcionais. Além disso, precisei implementar um max(0, total_receber) no retorno final. Afinal, se o funcionário pede demissão e falta no aviso prévio, os descontos podem superar os ganhos matematicamente, mas juridicamente o trabalhador não pode "sair devendo" a empresa.

Lá, eu também traduzi essa lógica para o Front-end e criei a calculadora online rodando na prática, onde você pode preencher os dados e ver a mágica acontecer em tempo real.

Link da acesso a calculadora e a explicação do código: https://descomplicandoalgoritmos.com.br/calculadora-de-rescisao-clt

Eu rodo alguns SaaS. Por um bom tempo pagava uns $300/mês em duas ferramentas separadas: uma para email transacional e outra para marketing e sequences.

Não era só o custo que incomodava. Era o trabalho manual. Entrar na ferramenta, montar template, configurar drip campaign... sendo dev, isso parece perda de tempo.

O ponto de virada veio numa conversa com o Pedro Campos, founder da templated.io. Ele me contou que tinha desistido de contratar uma ferramenta de email porque nenhuma tinha suporte a MCP. Quando ele falou isso eu pensei: se nem a gente, que é dev, quer fazer isso na mão, imagina os outros.

Pesquisei o mercado. Não achei nada parecido. Foi aí que comecei a codar o SendKit.dev.

O que aprendi no caminho:

O momento AHA precisa ser rápido

Usei o PostHog para rastrear onde os usuários travavam. O AHA moment do SendKit é mandar o primeiro email. Reconstruí o onboarding inteiro em volta disso. Você pega sua API key, a gente mostra o SDK, e você está enviando em literalmente um minuto.

Ninguém quer montar sequência de email
Por isso o SendKit é MCP native. Você fala pro seu AI agent criar uma sequência de onboarding e ele monta tudo: templates e automação.

Gravei uma demo onde crio um onboarding de 14 dias com 7 emails pro Changelogfy. O MCP foi no site, entendeu as cores, pegou o logo, entendeu o produto e montou todos os templates sozinho. O que antes levaria alguns dias, ficou pronto em 3 minutos.

Lista de supressão automática

Ninguém limpa lista. Então a lista tem que se limpar sozinha. Deu bounce, foi para supressão. Marcou como spam, mesma coisa. Sua reputação de envio fica protegida sem você precisar lembrar de nada.

Validação de email de verdade
Temos uma API separada de validação. Você manda um endereço e a gente responde se é real, descartável, catch-all ou email de função tipo admin@ e info@. Dá para usar no signup do seu produto e barrar fakes antes de entrarem na base.

Depois de um beta fechado com mais de 5 milhões de emails enviados, abrimos para todo mundo. Já passamos de 100 clientes.

Se você está cansado de pagar várias ferramentas que ainda exigem trabalho manual, vale conhecer o SendKit.dev.

Oferecemos 3.000 emails grátis por mês no plano free.

Boa tarde galera, vim trazer um pouco das atualizações do meu SaaS que postei aqui faz um pouco mais de 1 mês. Aproveitando, queria dar uma repassada sobre o que rolou de lá pra cá, os acertos e quais são os próximos passos.

Sempre quis fazer algo que realmente impactasse, e como estou inserido na comunidade DEV, acho que é o melhor lugar para encontrar e resolver dores reais. Peguei algo que eu mesmo já sofri no passado e que hoje as IAs ainda alucinam demais: pegar grandes documentos como extratos, contratos, boletos, fazer toda a extração de texto e imagem, e devolver em forma estruturada e sem alucinação.

A primeira coisa que fiz depois da primeira postagem aqui no TabNews foi tentar trazer pessoas para dar feedbacks, e nisso vocês foram brabos demais. Encontraram alguns bugs envolvendo navegadores tipo Brave e umas questões de créditos, o que consegui corrigir rápido.

Logo depois, fui para uma área que não tinha tanto conhecimento, o SEO. Certamente essa foi a melhor decisão que tomei. Na prática, foquei em fazer o básico bem feito: ajustei a semântica do HTML da landing page, melhorei o tempo de carregamento e comecei a atacar palavras-chave de cauda longa, focadas exatamente nas dores de quem lida com documentos o dia todo. Todo dia tenho visibilidade e pessoas novas entrando no meu site. Desse tráfego orgânico saíram meus primeiros clientes pagantes e 2 contratos enterprise que estou aguardando fechar. Hoje estou a poucos passos do meu Break Even, e como é bom trabalhar sabendo que o projeto já quase se paga, isso dá muito ânimo. Outra coisa muito boa com o SEO foi ver os termos que as pessoas pesquisam, o que vem validando demais a necessidade do Structura.

Uma coisa que notei foi que, apesar de equilibrar o site para 2 modelos (tanto API quanto dashboard), a grande procura foi para Enterprise. Faz muito sentido, quem trabalha com papéis com certeza lida com mais de 1000 páginas por mês.

Mas o maior destaque foi aprender na prática como o mercado B2B funciona. Notei que empresas querem segurança e contato próximo. Eles precisam saber que, se algo parar de funcionar ou surgir uma dúvida, eu estarei lá para resolver rapidamente. E como estou bem próximo e focado no projeto, conseguimos resolver tudo muito rápido.

Outra coisa que validei é que tratar o projeto como uma empresa séria desde o primeiro dia me trouxe muita credibilidade. Usar emails próprios, ter disparos organizados e tratar o Structura como uma estrutura sólida (apesar de ter poucas pessoas envolvidas) traz mais confiança tanto para o cliente quanto para mim na hora das conversas.

Meus próximos passos:

Agora estou focando em algumas melhorias. Notei que existem alguns atritos no começo da plataforma e alguns clientes encontram certa dificuldade para entender como funciona logo de cara, então vou trabalhar para facilitar esse primeiro contato. Além disso, estou melhorando um pouco mais o SEO e vou começar a rodar algumas campanhas pagas com Google Ads para ver o potencial de escala e validar novas ideias.

No mais, queria devolver um pouco do que aprendi. Se alguém tiver alguma dúvida, quiser saber mais sobre como foi esse início, a parte de SEO, ou como lidar com B2B no começo, deixa aí nos comentários que eu faço questão de responder.

E claro, pra quem sofre com extração de dados e quiser dar uma olhada de como a ferramenta está ficando, convido vocês a conhecerem o https://structura.com.br/.

Valeu galera!

Sabe quando você precisa:

• formatar um JSON
• decodificar um base64
• gerar um hash
• converter timestamp

E cai em sites lotados de propaganda, captcha e pop-up?

Eu cansei disso e comecei a criar minhas próprias ferramentas, focadas em:

• rapidez
• zero login
• uso direto

Subi algumas tools já em: https://quickeasy.tools

Meu objetivo é subir novas tools toda semana. Feedbacks são muito bem-vindos.
Vou adicionar novas toda semana.

O problema

Eu estou desenvolvendo um app que conecta pessoas com problema de vicio em pornografia (diaum).

Em algum momento eu bati em um problema que parece simples na teoria, mas na pratica é bem mais chato de resolver por que a maioria das soluçoes sao em ingles.

Repositorio.
Github

Live do projeto.
Teste o chat: Browser

Teste o chat: ToxiBr web

Moderaçao de chat.
Nao é sobre bloquear palavrao. Isso qualquer lista de palavras resolve.
O problema real é entender o contexto. O Diaum é um app que lida com um tema sensivel e uma coisa que acontece com frequencia é o usuario se colocar para baixo.

"eu me sinto um lixo"
"eu sou um bosta"

Se eu simplesmente bloqueasse essas palavras eu estaria silenciando exatamente o momento onde o usuario mais precisa falar.
Mas ao mesmo tempo eu nao posso permitir que um usuario ofenda o outro, foi daqui que nasceu a ToxiBR para resolver o meu problema e talvez o teu.

Voce pode ver a implementaçao dela no navegador aqui: ToxiBr web

O que é a ToxiBR?
A ToxiBR é uma biblioteca em JavaScript focada em moderaçao de conteudo em português com analise de contexto.
A ideia central é simples:

Nem toda palavra toxica deve ser bloqueada
Nem toda frase aparentemente inocente deve passar

Como funciona?
A ToxiBR trabalha com classificaçao de palavras e analise de contexto.

Cada palavra pode ter:

1. Um peso
2. Uma categoria
3. Uma regra de bloqueio

Categorias

1. Ofensa direta
2. Conteudo sexual
3. Racismo
4. Homofobia
5. Apologia
6. Dados pessoais

Tipos de tratamento

1. Hard block
2. Palavras que sao bloqueadas independente do contexto
3. Soft block

Palavras que dependem do contexto
Exemplo

"caralho hoje ta quente"

Aqui nao tem ataque a ninguem. É expressao.

Agora

"Pega no meu caralho"

Aqui muda completamente.

A ToxiBR tenta entender isso olhando o entorno da frase e a intencao.

Nao é perfeito.
Mas é muito melhor do que um if com lista de palavroes.

Proteçao de dados no chat

Outro problema que precisei resolver foi troca de informaçao pessoal.

1. Telefone
2. Endereco
3. Rede social

Em um ambiente anonimo isso quebra completamente a proposta.

Entao a ToxiBR tambem faz parsing de padroes:

1. Detecta numero de telefone
2. Detecta tentativa de enviar arroba de rede social
3. Detecta padroes de endereco
4. Analisa as ultimas 5 mensagens para detectar envio fracionado de dados

Tudo isso entra como categoria separada e pode gerar bloqueio ou alerta dependendo da regra.

Por que nao usar IA?
Essa pergunta sempre vem.
Por que nao usar uma LLM para moderar o chat?

Resposta curta
Privacidade e controle.
O Diaum é 100% anonimo. Nao existe log de conversa, nao existe armazenamento de mensagem

Enviar isso para um serviço externo quebraria tudo.
Principalmente a confiança do usuario.
Mesmo usando algo como o moderate: Ainda existe dependencia externa, Risco juridico, LGPD, Perda de controle

Casos de uso

1. Jogos online com chat
2. Comunidades anonimas
3. Apps de suporte emocional
4. Marketplaces com interaçao entre usuarios
5. Qualquer sistema com chat em tempo real

Se existe interaçao humana, existe necessidade de moderaçao.

Voce pode ver a implementaçao dela no navegador aqui: ToxiBr web

Limitaçoes
Nao existe soluçao perfeita.
Contexto é dificil,Ironia é dificil, sarcasmo é dificil, usuarios mal intencionados tambem
A ToxiBR resolve uma grande parte dos problemas mas ainda depende de evoluçao constante. Por isso é open source.
Se voce esta criando qualquer produto com interaçao entre pessoas voce vai enfrentar esse problema.

Mais cedo ou mais tarde e a pior coisa que voce pode fazer é ignorar isso no inicio.
A ToxiBR nasceu de um problema real dentro de um contexto sensivel com uma necessidade muito clara. Talvez ela resolva o seu tambem.