−0%
Payload do painel no 1º acesso
4,75 MB → 1,26 MB
Back-end em Go, TypeScript/Bun e Python. Construo serviços que conversam com equipamento industrial, aprendem com os dados e continuam testáveis sem o hardware ligado.
Construir um back-end em tempo real que lê o CLP, ajusta o controle sozinho e continua testável sem o equipamento ligado.
Execução
Conectado
Perfil
Stack
Resultados medidos em produção, no back-end que eu escrevo e mantenho.
−0%
4,75 MB → 1,26 MB
96,00ms
antes 96 ms · 300 mil registros
40→40
trocar de tela não reconecta o WebSocket
R$0mil/mês
algoritmos determinístico + random forest do pid-service
0contribuições
Back-end que roda dentro da planta do cliente e, antes disso, um ano mentorando uma comunidade de programação.
jun. de 2026 – o momento
atualComber Indústria LTDATempo integral
Back-end de dois produtos: uma plataforma em tempo real que roda embarcada em Raspberry Pi 5 e PCs industriais dentro da planta do cliente, e a aplicação web do administrativo para a comissão dos representantes. Os produtos são confidenciais. Aqui fica o lado de engenharia.
jul. de 2025 – jun. de 2026
encerradoBeroLabMeio período
Mentoria técnica e de carreira numa comunidade de programação.
Os dois sistemas que construo na Comber: um roda ao lado do equipamento, na planta do cliente; o outro fecha as comissões do comercial. São produtos confidenciais, então aqui entram só arquitetura e engenharia.
2026 — atualBack-end · Comber
Supervisão e controle adaptativo para equipamento industrial. Lê o CLP via Modbus, ajusta o PID episódio a episódio e entrega um supervisório web na rede da planta, tudo em contêineres que rodam de um Raspberry Pi 5 a um PC industrial.
Arquitetura da ISA: o CLP do equipamento conversa por Modbus TCP só com o core-isa, que repassa as leituras por HTTP ao pid-service e por WebSocket ao web-backend em Go. O web-backend grava em SQLite e é publicado pelo nginx do web-frontend, a única porta aberta para o navegador do operador. Tudo roda em Docker Compose num Raspberry Pi 5 ou num PC industrial.
2026 — atualBack-end · Comber
Sistema interno que lança vendas e recebimentos e calcula as comissões do comercial, com cadastros, dashboard e relatórios em PDF e Excel. Uma API em TypeScript sobre PostgreSQL que também serve o front-end.
Arquitetura do Comissões: o navegador chama /api na mesma origem; a API Express serve o build do React e acessa o PostgreSQL pelo Prisma, tudo em um contêiner e uma porta. No CI, o GitHub Actions roda lint, typecheck, migrations e testes contra um Postgres de teste isolado.
Os sistemas por trás dos números, animados a partir do código real. Nomes de planta e valores de calibração ficam de fora.
Um único dono da conexão Modbus lê o CLP uma vez por segundo e distribui a mesma leitura para o supervisório e para o serviço de ajuste adaptativo.
Diagrama animado: o CLP aceita uma única conexão Modbus TCP. O core-isa é o único dono dessa conexão, lê o CLP uma vez por segundo e publica a mesma leitura por WebSocket para dois consumidores: o web-service, supervisório em Go com Gin e SQLite, e o pid-service, que faz o ajuste adaptativo em Python. Mais navegadores abertos não geram tráfego extra no CLP.
Cada episódio mede overshoot, oscilação, offset e saturação. A primeira regra que casa ajusta P, I e D, sempre dentro de ±30% e dos limites.
Animação de três episódios de sintonia. Cada episódio tem 300 amostras de temperatura (cerca de 5 minutos), filtradas por mediana de 3. A partir do primeiro cruzamento do setpoint, a janela de regulação, saem overshoot, undershoot, oscilação e offset (desvio padrão e média do último quarto) e a fração de Hz saturado, que compõem um score ponderado: menor é melhor. As regras são avaliadas nesta ordem e a primeira que casa decide: 1, overshoot ou undershoot, aumenta D e reduz P; 2, Hz saturado ou varrendo a faixa, reduz P e aumenta D; 3, oscilação, reduz P e I; 4, offset abaixo do setpoint, aumenta I e P levemente; 5, offset acima, reduz P e I; senão mantém o PID. O PID sugerido passa pelos trilhos: no máximo ±30% por episódio e dentro dos limites. No exemplo, o episódio 1 tem overshoot e o D sugerido bate no limite; o episódio 2 oscila; o episódio 3 fica dentro da tolerância e o PID é mantido.
Depois de 20 episódios de regime, uma floresta de 80 árvores prevê o score de 125 combinações de P, I e D ao redor do atual e escolhe a menor.
Animação da camada de machine learning do pid-service. Enquanto o histórico tem menos de 20 episódios de regime, as regras determinísticas decidem. Com 20, um RandomForestRegressor de 80 árvores é treinado com P, I, D, nível e setpoint para prever o score do episódio. Ele avalia uma grade de 5 × 5 × 5 = 125 candidatos, cada ganho entre −30% e +30% do PID atual, e escolhe o de menor score previsto (argmin). A sugestão passa pelos mesmos trilhos das regras, ±30% por episódio e limites, e só é aplicada no modo drive; em shadow ela só é registrada e em off a camada fica desligada. Se as predições praticamente empatam (variação menor que 1%), as regras decidem. O loop alterna entre dois perfis de operação.
A senha mestre nunca sai da máquina. O cliente deriva as chaves e cifra cada item; o servidor só guarda blobs opacos que não consegue ler.
Diagrama animado do Guardian, gerenciador de senhas zero-knowledge. A senha mestre passa por Argon2id e vira a master key, que o HKDF-SHA256 divide em auth hash e enc key. Só o auth hash vai ao servidor, que guarda um Argon2id dele. A enc key nunca sai do cliente: ela abre a vault key com AES-256-GCM, e a vault key cifra cada item, inclusive o nome, com AES-256-GCM e AAD ligada ao usuário e ao item. O servidor recebe e guarda apenas blobs opacos no PostgreSQL.
Três linguagens, cada uma onde rende mais: Go nos serviços, TypeScript nas aplicações web e Python nos dados e na comunicação com o CLP.
go 1.27 · produção
Concorrência simples com goroutines e um binário único, sem runtime para instalar: ótimo para serviços de rede. Uso no supervisório web em Gin + SQLite (REST + WebSocket, JWT com refresh rotacionado e rate limit) e no Guardian, um gerenciador de senhas zero-knowledge com TUI.
$ go mod init github.com/guialvesrf/app go: creating new go.mod: module github.com/guialvesrf/app
ts 6 · api + web
A tipagem pega o erro antes de chegar em produção, e o Bun completa o par como runtime rápido, com bundler e test runner embutidos. Na aplicação de comissões, a API usa Express, Prisma e PostgreSQL, com testes automatizados e CI no GitHub Actions.
$ bun init -y + .gitignore + index.ts + tsconfig.json (for editor autocomplete) + README.md To get started, run: bun run index.ts
python 3.14 · dados + CLP
Ecossistema científico maduro: álgebra, estatística e machine learning sem reinventar nada. Uso no serviço de ajuste adaptativo (NumPy e random forest do scikit-learn), organizado em portas e adaptadores, e no core que conversa com o CLP via Modbus TCP.
$ python3 -m venv .venv && source .venv/bin/activate
1º lugar na Global Solution Future at Work 2025, o hackathon da FIAP realizado em 11 de novembro de 2025.
O Centro Universitário FIAP certifica que
Guilherme Alves Rodrigues Ferreira
Ganhou a Global Solution Future at Work 2025, realizado no dia 11 de novembro, com uma carga horária de 2 horas.
Desafio da FIAP com o tema Future at Work: pensar, construir e apresentar, contra o relógio, uma solução de tecnologia para o futuro do trabalho. O projeto ficou com o 1º lugar da edição 2025.
Engenharia de Software, na FIAP e agora na UniRV.
2026 – atual
UniRV · Universidade de Rio Verde
cursando2024 – 2025
FIAP
encerradoAberto a oportunidades como desenvolvedor back-end.
@guialvesrf em todas as redes