DEV Community: Guilherme Yamakawa de Oliveira

[PT-BR] McLovin: o roteador de links multiplataforma

Guilherme Yamakawa de Oliveira — Fri, 15 May 2026 18:37:44 +0000

Semana passada escrevi que roteamento de links é a feature que SO e browser fingem não existir, e fechei dizendo que essa era de IA podia trazer um roteador multiplataforma decente, e que eu seria o divulgador número um. O multiplataforma ainda não saiu, mas a parte do Linux saiu. Lanço hoje o McLovin.

Igual no Superbad, o McLovin se dá bem com o Sistema Operacional (Oficial Slater) e os browsers (Oficial Michaels). Amigo dos dois, ele direciona cada link pro lugar certo.

Menu principal da GUI

Por que o McLovin existe?

No Mac eu usava o Finicky. Migrei pro Linux com o Omarchy faz quase um ano e fui procurar equivalente. O Junction só pergunta a cada link, o mimi não tem regras de roteamento. Sobrava o caminho do "monta o teu", e eu montei. Funcionou muito bem, fiz uma TUI que combinava com o Omarchy. Aí pensei: isso aqui deveria existir em todo SO por padrão, igual a regra que cada SO tem pra escolher qual app abre PDF. Então decidi fazer o McLovin do jeito certo: um roteador multiplataforma, configurável por qualquer pessoa, com picker de browser quando precisar e regras pra mandar cada link pro lugar certo.

No iOS e no Android, esse problema também existe, mas fica pra depois.

O que é

O McLovin se registra como o handler default do sistema pra http e https. Quando você clica em qualquer link, no Slack, no terminal, ou em qualquer outro app, o SO entrega a URL pro McLovin. Ele lê o rules.toml, decide pra onde mandar, despacha o app ou browser certo, e some.

Se nenhuma regra bater, abre um picker no estilo Walker pra você escolher entre os browsers detectados. Dois frontends compartilham o mesmo core em Rust: uma CLI pra automação e keybinds, e uma GUI (mclovin settings) pra mouse e teclado.

Picker quando nenhuma regra bate

As regras

As regras vivem no ~/.config/mclovin/rules.toml. São três tipos: substring, regex com reescrita, e Lua pra regras dinâmicas. Um exemplo curto:

fallback_browser = "brave"

[[handler]]
match = "github.com/empresa"
command = "chrome --profile-directory='Profile 1' {url}"
description = "GitHub do trabalho no Chrome do trabalho"

[[handler]]
match_regex = '^https?://open\.spotify\.com/(\w+)/([^?#/]+)'
rewrite = "spotify --uri=spotify:{1}:{2}"
description = "Spotify aberto direto no app desktop"

[[handler]]
match_lua = "ctx.url.host:find('work') and ctx.now.hour < 18"
command = "chrome --profile-directory='Profile 1' {url}"
description = "Links de trabalho dentro do horário comercial"

O fallback_browser cobre o que não bate em nenhuma regra. O Lua roda num ambiente isolado (sem os.execute, sem loadfile) e recebe o contexto da URL, a hora atual, e o app que originou o clique. Receitas prontas pra colar saem com mclovin examples.

Lista de regras na GUI

Status

A versão alpha pra Linux já está funcionando. macOS e Windows vêm em breve. Pra qualquer problema, abra uma issue no GitHub do mclovin-release.

Onde ver

O manual de instalação, configuração e exemplos de regras está no site oficial:

mclovin.org

Finalizando

No post passado escrevi "eu, além de usar, seria o divulgador número um" de um roteador multiplataforma decente. Estou divulgando o meu. Falta o multiplataforma, mas no Linux já está entregue.

Publicado originalmente em guilherme44.com.

McLovin: the cross-platform link router

Guilherme Yamakawa de Oliveira — Fri, 15 May 2026 18:37:40 +0000

Last week I wrote that link routing is the feature OSes and browsers pretend isn't there, and closed by saying this AI era could bring a cross-platform router, and that I'd be the number one promoter. The cross-platform piece didn't ship yet, but the Linux piece did. Today I'm launching McLovin.

Just like in Superbad, McLovin gets along with the Operating System (Officer Slater) and the browsers (Officer Michaels). Friends with both, he steers each link to the right place.

Main menu of the GUI

Why does McLovin exist?

On Mac I used Finicky. I switched to Linux with Omarchy almost a year ago and went looking for an equivalent. Junction only asks every time, mimi doesn't carry routing rules. The remaining path was "build your own", and I did. It worked well, with a TUI that paired nicely with Omarchy. Then I thought: this should be a built-in feature on every OS, the same way each OS has a rule for which app opens PDFs. So I decided to do McLovin the right way: a cross-platform router, configurable by anyone, with a browser picker when nothing matches and rules to send every link to the right place.

iOS and Android have the same problem, but that's for later.

What it is

McLovin registers as the system's default handler for http and https. When you click any link, in Slack, in your terminal, or in any other app, the OS hands the URL to McLovin. It reads rules.toml, decides where to send it, dispatches the right app or browser, and gets out of the way.

If no rule matches, a Walker-style picker shows the detected browsers and lets you pick one. Two frontends share one Rust core: a CLI for automation and keybinds, and a GUI (mclovin settings) for mouse and keyboard.

Picker shown when no rule matches

The rules

Rules live in ~/.config/mclovin/rules.toml. Three kinds: substring, regex with rewrite, and Lua for dynamic rules. A short example:

fallback_browser = "brave"

[[handler]]
match = "github.com/work-org"
command = "chrome --profile-directory='Profile 1' {url}"
description = "Work GitHub in the work Chrome profile"

[[handler]]
match_regex = '^https?://open\.spotify\.com/(\w+)/([^?#/]+)'
rewrite = "spotify --uri=spotify:{1}:{2}"
description = "Spotify links opened in the desktop app"

[[handler]]
match_lua = "ctx.url.host:find('work') and ctx.now.hour < 18"
command = "chrome --profile-directory='Profile 1' {url}"
description = "Work links during business hours"

fallback_browser covers anything that doesn't match. Lua runs in a sandboxed environment (no os.execute, no loadfile) and receives the URL context, the current time, and the app that triggered the click. Ready-made recipes come from mclovin examples.

Rules list in the GUI

Status

The Linux alpha is working today. macOS and Windows are coming soon. Run into a problem? Open an issue on the mclovin-release GitHub.

Where to look

The full install guide, configuration manual, and rule examples live on the official site:

mclovin.org

Wrapping up

In the previous post I wrote "I'd be the number one promoter" of a decent cross-platform router. I'm promoting mine. The cross-platform part isn't there yet, but Linux is.

Originally posted at guilherme44.com.

[PT-BR] Pela terceira vez, o Google enfia coisa no seu PC sem perguntar

Guilherme Yamakawa de Oliveira — Fri, 08 May 2026 18:31:44 +0000

Se você usa o Chrome, tem 4GB de modelo de IA na sua máquina que você nunca pediu. E não é a primeira vez que o Google faz isso, é a terceira. O pesquisador Alexander Hanff publicou o relatório em 4 de maio de 2026. O arquivo se chama weights.bin, fica em OptGuideOnDeviceModel dentro do diretório do Chrome, e é o Gemini Nano. Sem aviso, sem checkbox. Se você descobrir e apagar, o Chrome baixa de novo no próximo restart.

A primeira reação aqui foi de déjà vu, não de surpresa. Em dezembro de 2020 o Loren Brichter (@lorenb no X, o cara do "pull to refresh" e do Tweetie, cliente que o Twitter comprou em 2010 pra virar o app oficial do iPhone) publicou o chromeisbad.com, um site de uma página explicando como o Keystone, o updater do Google Chrome no Mac, ficava rodando em background deixando o sistema lento mesmo com o Chrome fechado. A reclamação dele veio onze anos depois da Wired publicar "Google Software Update Tool is evil" sobre o mesmo Keystone, quando ele apareceu enfiado no Google Earth coletando dados de hardware e baixando coisas em background sem avisar. O remédio que o Brichter indicou foi escrever instruções pra desinstalar Chrome e Keystone na mão, e recomendar Safari, Brave, Vivaldi, Opera no lugar.

O que o Hanff descobriu

A descoberta dele é mais detalhada que a do Brichter em 2020. O Hanff cruzou logs de filesystem do macOS (.fseventsd), o Local State do Chrome, feature flags e logs do GoogleUpdater pra montar uma cadeia de evidências de quatro pontas. No perfil de teste dele, o weights.bin apareceu em 24 de abril de 2026 às 16:38:54 e levou 14 minutos e 28 segundos pra terminar de baixar. Silenciosamente. Cada perfil de Chrome roda esse processo de novo.

A versão afetada é a Chrome 147 e seguintes. O modelo serve pra features como "Help me write" (composição de texto), detecção local de scam e APIs que sites podem chamar (Summarizer API, Translator API, Prompt API).

A parte que dá raiva

Aquele botão chamativo de "AI Mode" que apareceu no omnibox do Chrome, que parece ser a feature visível de IA do browser, não usa o modelo local. As consultas digitadas ali vão pra cloud do Google. Ou seja: o usuário paga 4GB de download e 4GB de espaço em disco por um modelo que não roda quando ele clica no botão de IA do browser. O custo fica com o usuário, o uso fica com o Google.

Em escala

Hanff fez as contas: 0,24 kWh por dispositivo pra baixar e instalar, 0,06 kg de CO2e por dispositivo. Em 1 bilhão de instalações, são 240 GWh e 60 mil toneladas de CO2e, equivalente à emissão anual de cerca de 13 mil carros europeus. E com a União Europeia em cima do GDPR, da ePrivacy Directive (o Artigo 5(3) proíbe armazenar dados no dispositivo do usuário sem consentimento prévio) e da CSRD (a diretiva europeia de reporte de sustentabilidade), a chance de virar caso jurídico é alta.

Como tirar isso da sua máquina

O Google adicionou em fevereiro de 2026 a opção pra desabilitar:

Chrome Settings > System > "Turn On-device AI on or off", se a opção já apareceu pra você.
Caminho alternativo: digite chrome://flags na barra de endereço, busque por "optimization guide on device" e marque como "Disabled". Reinicie o Chrome.

Lembrando que apagar o weights.bin na unha não basta. Sem desabilitar a flag, o Chrome baixa de novo.

O que faço no meu dia a dia

Não uso o Chrome como browser principal há tempos. Escrevi semana passada sobre roteamento de links, e no setup que descrevo lá os browsers que abrem cada link são Chromium-based ou Firefox-based (Brave, Vivaldi, Edge, Opera, Helium), não o Chrome do Google em si. Os mesmos nomes, que o Brichter recomendou em 2020, continuam servindo bem em 2026.

A regra que adotei é simples. Não dá pra confiar num programa que decide instalar 4GB de IA, ou um daemon updater em background, sem te perguntar. O que tá em jogo não é só espaço em disco, é o controle sobre o que o seu computador faz quando você não tá olhando.

E lá vamos nós pela terceira vez

Em 2009 a Wired publicou que o Keystone era evil quando o Google enfiou ele junto com o Google Earth. Em 2020 o Brichter publicou o chromeisbad porque o mesmo Keystone tava dentro do Chrome. Agora em 2026 o Hanff mostrou que são 4GB de IA, instalados do mesmo jeito. Entre essas datas o Google só ficou maior, e a forma de empurrar coisa no PC dos outros sem perguntar não mudou.

Eu uso o Brave, e recomendo usar qualquer outro browser, menos o Google Chrome.

Fontes

Publicado originalmente em guilherme44.com.

For the third time, Google sneaks something onto your PC without asking

Guilherme Yamakawa de Oliveira — Fri, 08 May 2026 18:31:41 +0000

If you use Chrome, there are 4GB of an AI model sitting on your machine that you never asked for. And it is not the first time Google does this, it is the third. Privacy researcher Alexander Hanff published the report on May 4, 2026. The file is called weights.bin, lives in OptGuideOnDeviceModel inside the Chrome user data directory, and it is the Gemini Nano model. No prompt, no checkbox. Find it and delete it, and Chrome re-downloads it on the next restart.

The first reaction here was déjà vu, not surprise. In December 2020, Loren Brichter (@lorenb on X, the guy behind "pull to refresh" and Tweetie, the client Twitter bought in 2010 to become its official iPhone app) published chromeisbad.com, a one-page site explaining how Keystone, Google Chrome's updater on Mac, kept running in the background, dragging the system down even when Chrome was closed. His complaint came eleven years after Wired published "Google Software Update Tool is evil" about the same Keystone, when it showed up bundled with Google Earth, gathering hardware data and downloading things in the background without warning. Brichter's prescription was a manual uninstall guide for Chrome and Keystone, plus a list of replacements: Safari, Brave, Vivaldi, Opera.

What Hanff found

His discovery is more detailed than Brichter's was in 2020. Hanff cross-referenced macOS filesystem logs (.fseventsd), Chrome's Local State, feature flags, and GoogleUpdater logs to build a four-way evidence chain. On his test profile, weights.bin appeared on April 24, 2026 at 16:38:54 and took 14 minutes and 28 seconds to finish downloading. Silently. Each Chrome profile runs the process again.

The affected version is Chrome 147 onward. The model powers features like "Help me write" (text composition), local scam detection, and APIs that sites can call (Summarizer API, Translator API, Prompt API).

The frustrating part

That bright "AI Mode" pill that showed up in Chrome's omnibox, the visible AI feature of the browser, does not use the local model. Queries typed there are sent to Google's cloud. So the user pays 4GB of download and 4GB of disk for a model that does not run when they click the most prominent AI button on the browser. The cost lives with the user, the use lives with Google.

At scale

Hanff did the math: 0.24 kWh per device for the download and install, 0.06 kg of CO2e per device. At 1 billion installs, that is 240 GWh and 60,000 tonnes of CO2e, equivalent to the annual emissions of about 13,000 European cars. And with the European Union watching closely on GDPR, the ePrivacy Directive (Article 5(3) prohibits storing data on a user's device without prior consent), and the Corporate Sustainability Reporting Directive, the chance of this turning into a legal case is high.

How to remove it

Google added an opt-out in February 2026:

Chrome Settings > System > "Turn On-device AI on or off", if the option is showing up for you yet.
Alternative path: type chrome://flags in the address bar, search for "optimization guide on device", and set it to "Disabled". Restart Chrome.

Note that deleting weights.bin by hand is not enough. Without disabling the flag, Chrome downloads it again.

What I do in my daily setup

I have not been using Chrome as my main browser for a long time. I wrote last week about link routing, and in the setup I describe there the browsers that open each link are Chromium-based or Firefox-based (Brave, Vivaldi, Edge, Opera, Helium), not Google's own Chrome. The same names, recommended by Brichter back in 2020, still serve well in 2026.

The rule I keep is simple. You cannot trust a program that decides to install 4GB of AI weights, or a background updater daemon, without asking you. What is at stake is not just disk space, it is control over what your computer does when you are not looking.

And here we go for the third time

In 2009 Wired called Keystone evil when Google bundled it inside Google Earth. In 2020 Brichter published chromeisbad because the same Keystone was now sitting inside Chrome. Now in 2026 Hanff showed that 4GB of AI weights are being pushed the same way. Between those dates Google only got bigger, and the way it pushes things onto other people's machines without asking has not changed.

I use Brave, and my recommendation is any browser, just not Google Chrome.

Sources

Originally posted at guilherme44.com.

Awesome!!

Guilherme Yamakawa de Oliveira — Tue, 05 May 2026 02:22:44 +0000

Amanda Gama

May 5

A Live Activity isn't a notification

#showdev #ios #mobile #tutorial

6 min read

[PT-BR] Roteamento de links: a feature que SO e browser fingem não existir

Guilherme Yamakawa de Oliveira — Sun, 03 May 2026 21:57:23 +0000

Migrei do Mac pro Linux com Omarchy faz quase um ano. Quase tudo voltou ao lugar. Tem uma coisa que continua incomodando, e percebi que o problema é maior do que parecia. Existe uma funcionalidade simples que Sistema Operacional nenhum entrega e browser nenhum entrega: regra pra decidir qual browser ou app abre cada link clicado.

No Mac eu usava o Finicky pra isso. Pra quem nunca viu: ele deixa você criar regras que decidem qual browser abre cada link. Você coloca o Finicky como browser padrão do sistema, e ele aplica suas regras a cada link clicado em qualquer app, escolhendo o browser certo. As regras são pequenos scripts em JavaScript, simples ou mais elaborados conforme a necessidade. Dá até pra reescrever a URL antes de abrir, tipo forçar HTTPS, remover parâmetros de rastreamento, ou converter num link interno que abre o app desktop diretamente. Se nenhuma regra bater, ele cai num browser de reserva que você define.

Na prática, é assim. Link de github.com/empresa abre no browser do trabalho, github.com/pessoal no browser pessoal. meet.google.com cai logado no perfil certo. Vídeo de YouTube volta sempre pro browser principal. Qualquer link que não bater em nenhuma regra cai no de reserva, no meu caso o browser pessoal. Trabalho e vida pessoal separados sem ter que copiar URL e colar na outra janela.

E tem o caso dos apps que vêm com versão desktop e usam um endereço próprio que abre eles direto. Spotify, WhatsApp, Slack, Discord, Zoom, cada um tem um endereço interno tipo spotify:, whatsapp:, slack:, que o sistema entende como "esse link é desse app, abre aqui". Quando alguém compartilha um link público (open.spotify.com/track/..., wa.me/<numero>, chat.whatsapp.com/<convite>), o ideal é abrir direto no app desktop, não numa aba de browser que vai pedir login e perguntar "abrir no app?" toda vez. No Finicky você escreve uma regra que reconhece o link público e reescreve pro endereço interno do app (open.spotify.com/track/abc vira spotify:track:abc, wa.me/5511... vira whatsapp://send?phone=...), e o sistema entrega direto pro app. Aba intermediária zero.

Solução simples, efeito grande. É aí que tá o estranho.

O que existe no Linux

Procurei equivalente e o que mais aparece é o Junction: bonito, ativo, bem mantido. Mas ele só pergunta qual browser usar a cada link. Não tem regras, não decide sozinho. Tem pedido aberto na comunidade pra ele lembrar de uma escolha padrão e só perguntar quando você segurar Alt, mas ninguém pegou pra implementar. Junction só pergunta, não roteia.

O mimi é uma alternativa mais decente ao mecanismo padrão do Linux que abre links (xdg-open), mas também não traz regras de roteamento prontas.

Fora isso, sobra o caminho velho: criar um atalho próprio na pasta de apps do usuário (~/.local/share/applications/), marcar esse atalho como o programa que vai abrir os links do sistema, e escrever um pequeno script que faz o roteamento na mão. Funciona, mas é peça caseira que cada um tem que manter por conta própria, sem comunidade no meio.

O mais perto que tem hoje de Finicky no Linux é "monta o teu".

E no Mac?

No Mac a paisagem é viva. Finicky tá em desenvolvimento ativo, lançou v4.2.2 em outubro de 2025 com editor visual de regras. Tem Velja, Choosy, Default Tamer, Yojam. Mercado inteiro de ferramenta de terceiro tapando o mesmo buraco.

Editor visual de regras do Finicky

E mesmo no Mac essa cena tem casualty. O Browserosaurus, outro favorito da galera, foi arquivado em 2 de agosto de 2025. Mantenedor cansou, sem sucessor oficial. Comunidade tem fork, ninguém é o canônico.

É o que costuma acontecer com ferramenta de terceiro que vive pra cobrir o que SO e browser deixam aberto.

E no Windows?

No Windows a história é a mesma. Você define um único browser pra abrir todos os links do sistema, ponto. Não tem como dizer "esse site abre aqui, esse outro abre lá".

A novidade recente é que o Edge ganhou em 2025 uma opção pra quem tem conta corporativa Microsoft (Entra ID, antiga Azure AD): link externo cai automaticamente no profile de trabalho do Edge. É só uma opção global. Você escolhe um profile e acabou. Sem regra por URL, sem distinção de qual app abriu o link.

Fora do Edge, a cena de terceiro no Windows é até maior do que no Linux. O Hurl (ativo) e o BrowserPicker do mortenn (na Microsoft Store) lideram. O BrowseRouter é um fork ativo do BrowserSelector original, que foi arquivado em 2022. Tem também o Switchbar, comercial e que roda no Mac e no Windows.

Mesmo padrão de sempre. Terceiro tampa o que SO e browser não tampam, e quando o terceiro arquiva (oi, BrowserSelector) a comunidade aparece com fork, ninguém vira o canônico.

Por que nenhum Sistema Operacional entrega

O modelo que existe nos SOs hoje é o mesmo em todo lugar. macOS, Windows, Linux. Pra cada tipo de link, você escolhe um único app que vai abrir e pronto. Link de site (https)? Um browser. Email (mailto)? Um cliente de email. Música (spotify)? Um app. Não dá pra dizer "esse link específico vai pra outro app", nem "esse link veio do Slack, então abre em outro lugar". Cada SO chama esse mecanismo de um nome diferente (xdg-mime no Linux, LaunchServices no Mac, registry no Windows), mas a limitação é a mesma.

Linux teria espaço pra ir além já que esse mecanismo é convenção, não imposição, mas ninguém moveu. macOS e Windows nunca abriram uma forma oficial pra você definir regras de roteamento de link. Trinta anos de SO desktop, e a ideia de "esse link tem que abrir aqui, esse outro tem que abrir lá" continua fora do escopo do sistema.

Por que browser nenhum entrega

Chrome tem um seletor pra escolher qual perfil do próprio Chrome abre o link. Firefox tem "containers" (uma forma de isolar abas em compartimentos separados), e com extensão (Containerise, Auto Containers) dá pra rotear por padrão de URL, mas tudo isso só funciona dentro do Firefox. Nenhum browser quer mandar tráfego pra outro browser. Cada um quer ser o browser padrão do sistema.

Faz sentido pelo incentivo. Mandar link pra outro browser primeiro reduz a métrica que importa pra cada empresa, que é link aberto no produto deles. Pelo lado da segurança também tem desculpa: um único browser padrão de confiança é mais simples de auditar do que um esquema que decide pra onde mandar com base em regrinha de URL. Nada disso explica o tamanho do silêncio dos SOs.

Enquanto isso

Faz mais de dez anos que esse problema é o mesmo. SO e browser fingem que rotear link não é responsabilidade deles, e toda vez que aparece terceiro pra resolver, ele vira projeto solo até o mantenedor cansar. Aí volta todo mundo pra estaca zero (oi, Browserosaurus).

Separar link clicado por regra é tarefa básica de quem trabalha com mais de um contexto no mesmo computador. Devia estar na base do sistema, no mesmo nível de "qual app abre PDF". Faz dez anos esperando.

Seria muito bom essa era de IA finalmente trazer um multiplataforma decente para todos. Mac, Windows e Linux na mesma ferramenta. Eu, além de usar, seria o divulgador número um. Mercado pra ele a gente sabe que tem.

Fontes:

Publicado originalmente em guilherme44.com.

Link routing: the feature OSes and browsers pretend isn't there

Guilherme Yamakawa de Oliveira — Sun, 03 May 2026 21:57:19 +0000

I switched from Mac to Linux with Omarchy almost a year ago. Most things slid back into place. There's one thing still bothering me, and turns out it's not just a Linux problem. There's a simple feature no OS ships and no browser ships: rules for deciding which browser or app opens each link you click.

On Mac I used Finicky for this. For anyone who never saw it: it lets you write rules that decide which browser opens each link. You set Finicky as the system's default browser, and it applies your rules to every link clicked in any app, picking the right one. Rules are short scripts in JavaScript, simple or as elaborate as you need. It can even rewrite the URL before opening it: force HTTPS, strip tracking parameters, or convert it into an internal link that opens the desktop app directly. If no rule matches, it falls through to a backup browser you define.

In practice, it looks like this. A github.com/work-org link opens in the work browser, github.com/personal in the personal one. meet.google.com lands logged into the right profile. YouTube videos always come back to the main browser. Anything that matches no rule falls through to the backup, in my case the personal browser. Work and personal life kept apart without copy-pasting URLs into another window.

There's also the case of apps that ship a desktop client and use their own private address to open it directly. Spotify, WhatsApp, Slack, Discord, Zoom, each has an internal address like spotify:, whatsapp:, slack:, which the system reads as "this link belongs to that app, open it there". When someone shares a public link (open.spotify.com/track/..., wa.me/<phone>, chat.whatsapp.com/<invite>), the right move is to open it straight in the desktop app, not in a browser tab that asks for login and prompts "open in app?" every single time. With Finicky you write a rule that matches the public link and rewrites it to the app's internal address (open.spotify.com/track/abc becomes spotify:track:abc, wa.me/15551234567 becomes whatsapp://send?phone=...), and the system hands it straight to the app. No intermediate tab.

Simple solution, big payoff. That's the strange part.

What exists on Linux

Searched for an equivalent and the most common answer is Junction: pretty, active, well maintained. But it only asks which browser to use on every link. No rules, no auto-routing. There's a community request asking it to remember a default choice and only ask when you hold Alt, but nobody has picked it up. Junction only asks, it doesn't route.

mimi is a more decent replacement for the Linux mechanism that opens links (xdg-open), still without ready-made routing rules.

What's left is the old path: drop a custom shortcut file in the user's apps folder (~/.local/share/applications/), mark that shortcut as the program that opens the system's links, and write a small script that does the routing by hand. It works, but it's a homebrew piece each user has to maintain on their own, with no community in the middle.

The closest thing to Finicky on Linux today is "build your own".

And on Mac?

The Mac landscape is alive. Finicky is actively developed, with v4.2.2 out in October 2025 bringing a visual rules editor. There's Velja, Choosy, Default Tamer, Yojam. A whole third-party market plugging the same gap.

Finicky's visual rules editor

Even there it has casualties. Browserosaurus, another community favorite, was archived on August 2, 2025. Maintainer burned out, no official successor. Community has forks, none is canonical.

That's what tends to happen to any third-party tool plugging a gap that neither the OS nor the browser wants to plug.

And on Windows?

On Windows, same story. You set one browser to handle every link in the system, period. No way to say "this site opens here, that other one opens there".

The recent twist is that in 2025 Edge added a toggle for users on a Microsoft corporate account (Entra ID, formerly Azure AD): external links automatically land in Edge's work profile. It's just a global toggle. You pick a profile and that's it. No URL rules, no awareness of which app opened the link.

Outside Edge, the third-party scene on Windows is actually bigger than on Linux. Hurl (active) and mortenn's BrowserPicker (on the Microsoft Store) lead the pack. BrowseRouter is an active fork of the original BrowserSelector, which was archived in 2022. There's also Switchbar, commercial and running on both Mac and Windows.

Same old pattern. Third-party plugs what OS and browser won't, and when the third-party gets archived (hi, BrowserSelector) the community spins up forks, none becoming the canonical one.

Why no OS ships this

The model across operating systems is the same everywhere. macOS, Windows, Linux. For each kind of link, you pick one app that opens it, end of story. A web link (https)? One browser. Email (mailto)? One mail client. Music (spotify)? One app. No way to say "this specific link goes to a different app", or "this link came from Slack so open it somewhere else". Each OS calls this mechanism by a different name (xdg-mime on Linux, LaunchServices on macOS, the registry on Windows), but the limit is the same.

Linux has room to go further since this mechanism is convention, not enforcement, but nobody has moved. macOS and Windows never opened a public API for routing links by rule. Thirty years of desktop OS, and the idea of "this link belongs here, that other link belongs there" still sits outside the system's scope.

Why no browser ships this

Chrome has a selector for picking which profile of Chrome itself opens the link. Firefox has "containers" (a way to isolate tabs into separate compartments), and with extensions (Containerise, Auto Containers) you can route by URL pattern, but all of that only works inside Firefox. No browser wants to hand traffic over to another browser. Each one wants to be the system's default browser.

The incentive math is clear. Sending links to a different browser first reduces the metric that matters for each company, links opened in their own product. The security argument is also there: one trusted default browser is easier to audit than a system that decides where to send things based on URL-matching rules. None of that explains the size of the silence on the OS side.

Meanwhile

This problem has been the same for over ten years. OSes and browsers act like routing a link isn't their responsibility, and every time a third-party tool steps up to fix it, it ends up a solo project until the maintainer burns out. Then everyone goes back to square one (hi, Browserosaurus).

Splitting clicked links by rule is a basic task for anyone juggling more than one context on the same machine. It belongs in the base of the system, at the same level as "which app opens PDFs". Been ten years waiting.

It would be great for this AI era to finally bring a decent cross-platform one for everyone. Mac, Windows and Linux in the same tool. Beyond just using it, I'd be its number-one evangelist. The market is there, we all know that.

Sources:

Originally posted at guilherme44.com.

[PT-BR] Por que troquei meu "Opinionated Linux" autoral (DIY) pelo Omarchy

Guilherme Yamakawa de Oliveira — Sat, 02 May 2026 12:23:32 +0000

Tô usando o Omarchy como setup principal desde 26 de junho de 2025, dia em que o DHH lançou a primeira versão. Antes tinha meu "Opinionated Linux" autoral (DIY), o mclovin-ARCHived: um installer Arch + i3wm com tudo configurado do meu jeito. Era controle total sobre o SO: eu decidindo o que entra, mantendo cada peça (i3wm, polybar, picom, kitty, dotfiles) atualizada e fazendo elas conversarem entre si pra o SO inteiro funcionar. Servia bem, mas era custoso de manter atualizado: sempre desbravando algum TUI novo pra resolver um probleminha, e trocar de CPU ou notebook era ver compatibilidade de tudo e ajustar pra cada máquina.

O Omarchy resolveu isso entregando o mesmo tipo de setup, só que com uma comunidade inteira por trás, trabalhando e discutindo melhorias toda semana. Aprendo algo novo o tempo todo.

Tema: Osaka Jade

Por que o Omarchy

O Omarchy é uma distro Arch opinativa criada pelo David Heinemeier Hansson (DHH), criador do Rails, do Basecamp e do Hey. Por baixo é Arch Linux + Hyprland, mas vem com tudo pré-configurado: lock screen, menu bar, bluetooth, temas, atalhos. Nada de instalar pacote por pacote.

O que me convenceu: Hyprland puro é bonito mas cru. Sozinho ele te deixa configurando coisas básicas por semanas. O Omarchy escolhe defaults bons e te entrega um sistema pronto pra trabalhar poucos minutos depois do boot.

É irmão do Omakub, versão Ubuntu da mesma ideia. Quem quer Linux com curva mais suave vai pro Omakub, quem quer Arch sem perder dois dias configurando vai pro Omarchy.

Temas

Um dos pontos fortes do Omarchy é a comunidade de temas. O omarchythemes.com reúne dezenas de temas prontos pra instalar com um comando, e a paleta inteira muda junta: terminal, editor, status bar, lock screen, wallpaper. E a troca é instantânea. Um atalho, dois segundos, todo o sistema já tá com o novo visual. Impressionante toda vez. A hero shot lá em cima tá com o Osaka Jade. Abaixo, um dia a dia com o Rose of Dune.

Tema: Rose of Dune

De onde vim

Voltei pro Linux saindo de um MacBook M1 com 16GB de RAM. Vários fatores pesaram: o Docker estourava a memória e no Mac RAM é soldada, não dá pra subir, precisa comprar um novo (e configurar com mais memória vira coisa burocrática e cara); pra ter um tiling window manager precisava desabilitar parte da proteção do sistema (o SIP) pra forçar o Yabai (tiling WM pra Mac), e qualquer update do macOS quebrava algo; e queria saber o que tava rodando na máquina, já que Mac, Windows e até Ubuntu vêm cheios de coisa que você não pediu, mandando telemetria sem transparência. Até o Chrome no macOS instala um daemon silencioso chamado Keystone por trás (vale ler o chromeisbad.com). Trocar pra Arch era o caminho natural.

Construí o mclovin-ARCHived pra automatizar a instalação do meu setup Arch + i3wm + polybar + neovim + dotfiles. O nome era referência ao McLovin do filme Superbad, era basicamente meu "script superbad".

A referência inicial foi o Omakub do DHH, que mostrou o padrão "rodar um script e ter tudo pronto". Não fui pro Omakub direto porque anos atrás já tinha usado muito Ubuntu e não curtia o estilo do GNOME, queria algo mais personalizável e tiling. Mas a ideia ficou.

Outras inspirações:

ML4W, outro projeto de automação de Arch que cheguei perto de adotar
typecraft_dev no YouTube, com tutoriais de Hyprland, i3wm, Neovim e Arch
caffeine.wiki/x220, onde o Rodrigo Franco (caffo) personalizou o Arch + dwm num Thinkpad X220 pra ter uma máquina barata, durável e discreta pra trabalhar em qualquer canto (cafezinho de bairro suspeito incluso)

O installer fazia o trabalho. Mas era trabalho de manter sozinho.

Por que migrei

Ter installer próprio é divertido até o dia que você precisa fazer o display manager funcionar com a webcam nova. Ou descobrir que aquele AUR helper que você escolheu três anos atrás virou abandonware. Ou ver que o tema do polybar quebrou porque a fonte mudou de nome num update.

Tudo isso é resolvível. Mas resolvível por uma pessoa só não escala bem.

Como uso Ruby on Rails, sempre acompanhei o trabalho do DHH. O Rails é o que ele chama de omakase (em japonês, "deixa comigo, eu escolho"): você usa os defaults bons que vieram com a caixa, sem ficar configurando cada peça. Omakub levou a mesma ideia pro Ubuntu, e em junho de 2025 saiu o Omarchy, omakase pra Arch + Hyprland. Continuação natural. Entrei no dia 1.

Acompanhar cada release desde o início faz parte da graça. O sistema fica mais redondo a cada versão, e a vista de perto da evolução compensa uns perrengues no caminho.

Quando faz sentido pra você

Antes da checklist prática: o Omarchy faz sentido se você é curioso pra entender como Linux funciona na prática. Vai acompanhar o projeto, atualizar, eventualmente quebrar o SO e ter que formatar pra arrumar. Não é caminho pra qualquer um. Mas é assim que se ganha conhecimento real de como o sistema funciona, em vez de só usar de longe.

Omarchy é ótimo se você:

Quer Arch + tiling WM mas não quer gastar dias configurando
Curte a pegada omakase: defaults opinativos, convenção sobre configuração
Tá disposto a aprender Hyprland (ele tem suas pegadinhas)

Sobre hardware: roda bem até em máquinas antigas. Vários Macs com Intel que estavam parados em gaveta voltaram pra ativa rodando Omarchy. Alguns hardwares ficam mais difíceis de configurar, mas a comunidade no Discord e no GitHub do projeto geralmente já passou pelo problema e ajuda a resolver.

Não é pra você se quiser configurar cada bit do sistema na mão (nesse caso, Arch puro é o caminho), ou se prefere KDE/GNOME (Omarchy é Hyprland-only por design).

Finalizando

Manter um installer próprio de Linux foi uma fase boa, aprendi muito. Mas chegar no Omarchy é poder usar a mesma filosofia sem ser o único responsável por mantê-la.

Formato o computador e em poucos minutos tenho tudo configurado de novo. Mac não funciona bem assim, Windows muito menos.

E nem tudo é escrito em pedra. Ainda quero montar um "Opinionated Script" pro macOS com keybindings e tiling window manager parecidos com o do Omarchy, já que preciso do macOS pra usar Xcode e publicar pra iOS. Faz sentido deixar a máquina configurada na mesma pegada, sem ter que viver dentro dela. Com IA hoje, montar um script desse é tranquilo.

Pra quem quer Arch produtivo no dia a dia sem virar o mantenedor solo, Omarchy é a melhor pedida.

Fontes:

Publicado originalmente em guilherme44.com.

Why I traded my custom "Opinionated Linux" for Omarchy

Guilherme Yamakawa de Oliveira — Sat, 02 May 2026 12:23:28 +0000

I've been using Omarchy as my main setup since June 26, 2025, the day DHH released the first version. Before that I had my own custom Opinionated Linux, mclovin-ARCHived: an Arch + i3wm installer set up exactly the way I liked. It was total control over the OS: me deciding what goes in, keeping every piece (i3wm, polybar, picom, kitty, dotfiles) up to date and making sure they all talked to each other for the whole OS to keep working. It did the job, but it was costly to keep up to date: always digging into some new TUI to solve a small issue, and changing CPU or laptop meant checking compatibility for everything and tweaking for each machine.

Omarchy solved that by delivering the same kind of setup, but with a whole community behind it, working and discussing improvements every week. I learn something new all the time.

Theme: Osaka Jade

Why Omarchy

Omarchy is an opinionated Arch distro created by David Heinemeier Hansson (DHH), creator of Rails, Basecamp and Hey. Under the hood it's Arch Linux + Hyprland, but it ships with everything pre-configured: lock screen, menu bar, bluetooth, themes, keybindings. No installing packages one by one.

What sold me on it: bare Hyprland is beautiful but raw. On its own, it leaves you configuring basics for weeks. Omarchy picks good defaults and hands you a system that's ready to work a few minutes after boot.

It's the sister project to Omakub, the Ubuntu version of the same idea. People who want Linux with a softer learning curve go for Omakub; people who want Arch without losing two days configuring it go for Omarchy.

Themes

One of Omarchy's strong points is the theme community. omarchythemes.com collects dozens of themes ready to install with a single command, and the whole palette switches together: terminal, editor, status bar, lock screen, wallpaper. And the switch is instant. A keybind, two seconds, the whole system already on the new look. Impressive every time. The hero shot up top is the Osaka Jade theme. Below, a day-to-day setup with the Rose of Dune.

Theme: Rose of Dune

Where I came from

Came back to Linux from a MacBook M1 with 16GB of RAM. A few things piled up: Docker would eat through memory and RAM on a Mac is soldered, you can't upgrade, you have to buy a new one (and speccing one with more memory gets bureaucratic and expensive); for a tiling window manager I had to disable part of the system's security (SIP) to force Yabai (tiling WM for Mac), and any macOS update would break something; and I wanted to know what was actually running on the machine, since Mac, Windows and even Ubuntu come packed with stuff you never asked for, shipping telemetry without much transparency. Even Chrome on macOS installs a silent daemon called Keystone in the background (worth reading chromeisbad.com). Switching to Arch was the natural move.

I built mclovin-ARCHived to automate the install of my Arch + i3wm + polybar + neovim + dotfiles setup. The name was a reference to McLovin from the movie Superbad, it was basically my own "superbad script".

The initial reference was Omakub by DHH, which showed me the "run a script and have everything ready" pattern. I didn't go for Omakub directly because I'd used Ubuntu a lot years ago and wasn't into the GNOME style, I wanted something more customizable and tiling. But the idea stuck.

Other inspirations:

ML4W, another Arch automation project I came close to adopting
typecraft_dev on YouTube, with tutorials on Hyprland, i3wm, Neovim and Arch
caffeine.wiki/x220, where Rodrigo Franco (caffo) tuned Arch + dwm on a Thinkpad X220 for a cheap, durable and low-profile machine he could use anywhere (sketchy coffee shops included)

The installer did the job. But it was solo work to maintain.

Why I switched

Having your own installer is fun until the day you need to make the display manager work with a new webcam. Or you find out the AUR helper you picked three years ago is now abandonware. Or the polybar theme breaks because the font got renamed in some update.

All solvable. But solvable by one person doesn't scale well.

Since I work with Ruby on Rails, I've been following DHH's work for years. Rails is what he calls omakase (Japanese for "I'll leave it to you"): you take the good defaults that came in the box, instead of configuring every piece. Omakub took the same idea to Ubuntu, and in June 2025 came Omarchy, omakase for Arch + Hyprland. Natural continuation. I jumped in on day 1.

Following every release from the start is part of the appeal. The system gets more polished with each version, and the up-close view of the evolution makes up for any rough patches along the way.

When it makes sense for you

Before the practical checklist: Omarchy makes sense if you're curious about how Linux actually works under the hood. You'll follow the project, update, eventually break the OS and have to format to fix it. Not a path for everyone. But that's how you end up with real knowledge of how the system works, instead of just using it from a distance.

Omarchy is great if you:

Want Arch + tiling WM but don't want to spend days configuring
Are into the omakase approach: opinionated defaults, convention over configuration
Are willing to learn Hyprland (it has its quirks)

About hardware: it runs well even on older machines. Several old Intel Macs that had been sitting in drawers are back in action running Omarchy. Some hardware takes more work to configure, but the community on the project's Discord and GitHub has usually been there before and helps you sort it out.

Not for you if you want to configure every bit of the system by hand (in which case bare Arch is the path), or if you prefer KDE/GNOME (Omarchy is Hyprland-only by design).

Wrapping up

Keeping my own Linux installer was a good phase, taught me a lot. But landing on Omarchy means I get to use the same philosophy without being the only one responsible for maintaining it.

I can wipe the machine and have everything configured again in a few minutes. Macs don't work that way, Windows even less.

And nothing's set in stone. I still want to build an "Opinionated Script" for macOS with keybindings and a tiling window manager similar to Omarchy, since I need macOS to use Xcode and ship apps to iOS. Makes sense to have the machine set up in the same vibe without having to live inside it. With AI these days, putting a script like that together is straightforward.

If you want productive Arch in your day to day without being the solo maintainer, Omarchy is the way.

Sources:

Originally posted at guilherme44.com.

Using MinIO with Rails

Guilherme Yamakawa de Oliveira — Fri, 01 May 2026 03:27:57 +0000

I'm on a project where the file upload setup uses Active Storage with Amazon S3. But there's no configuration for me to download files from S3 and use them in development.

When I looked at config/storage.yml I saw the following:

local:
  service: Disk
  root: <%= Rails.root.join("storage") %>

I figured it would be simple, just bring everything inside the S3 Bucket into the app's app/storage folder.

I downloaded the AWS CLI and set it up with my credentials.

Then I synced the S3 files into my app/storage folder:

$ aws s3 sync s3://bucket-name ~/Projects/selected-project/storage

Started the app and it didn't work 🙄.

In ActiveStorage, when the configured service is Disk, after the blob generates the key, the file is saved inside two folders and then the blob key.

I checked the file path in the console and it returned:

> user = User.first
> ActiveStorage::Blob.service.send(:path_for, u.avatar.key)
=> "storage/jt/Y7/jtY7656jGPvfPMUUA8kX6Vb4"

I noticed those folders were the first 4 characters of the key.

I thought of a few solutions:

Write a script to generate those subfolders and place the files in them.

I didn't go with this. It might not work, and since I don't have experience with scripts that change the filesystem, I figured it would take too long.
Check how Active Storage generates path_for and tell it to generate directly without those subfolders.

I searched and didn't find anywhere I could do that.
Duplicate the bucket inside S3 and use it for development.

Didn't like the idea, I'd have to pay for storing 2 buckets.
Use MinIO.

This was the option I figured was fastest and had the best cost-benefit.

For those who don't know, MinIO is an Open Source project written in Go, designed from the start to be the standard for object storage in private cloud. It's a cloud-native object server with concurrent, scalable and lightweight performance (more info).

I need to set up MinIO like S3, since the app needs to think it's talking to S3. I downloaded MinIO from their site and set up the environment variables:

export MINIO_ACCESS_KEY="minio_storage_development"
export MINIO_SECRET_KEY="minio_storage_development"
export MINIO_REGION_NAME="us-east-1"

It's configured through environment variables. You can check all the settings in the docs. (MinIO docs)

Now just start it:

$ minio server ~/minio_storage

Endpoint:  http://xxx.xxx.xxx.xxx:9000  http://xxx.xxx.xxx.xxx:9000  http://127.0.0.1:9000
AccessKey: minio_storage_development
SecretKey: minio_storage_development
Region:    us-east-1

Browser Access:
  http://xxx.xxx.xxx.xxx:9000  http://xxx.xxx.xxx.xxx:9000  http://127.0.0.1:9000

Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide
  $ mc config host add myminio http://100.100.101.162:9000 minio_storage_development minio_storage_development

Note: I hid my IP with xxx.xxx.xxx.xxx because it's static and I don't want it exposed to the web.

There you go, a MinIO server running on your machine.

I accessed it through my browser at http://127.0.0.1:9000/ using the Access Key and Secret Key, and created a Bucket called rails_app_bucket.

In the Rails settings at config/storage.yml:

local:
  service: S3
  endpoint: http://127.0.0.1:9000
  access_key_id: minio_storage_development
  secret_access_key: minio_storage_development
  region: us-east-1
  bucket: rails_app_bucket
  force_path_style: true

I moved all the files I had downloaded from the S3 bucket into the MinIO bucket folder:

$ mv ~/Projects/selected-project/storage/* ~/minio_storage/rails_app_bucket

To sync files from S3 I now use:

$ aws s3 sync s3://bucket-name ~/minio_storage/rails_app_bucket

I also added MinIO to my Procfile.development so the server starts whenever I run the app through foreman:

# Procfile.development

server: bin/rails server
webpacker: bin/webpack-dev-server
redis: redis-server
sidekiq: bundle exec sidekiq
minio: minio server ~/minio_storage

Conclusion

It became really simple to sync the files and not get any 404 errors when running the app, or that Rails error saying the file doesn't exist.

Originally posted at guilherme44.com.

[PT-BR] Slash commands: chega de commits sem sentido

Guilherme Yamakawa de Oliveira — Fri, 01 May 2026 03:27:22 +0000

Uma das coisas que mais uso desde que comecei com o Claude Code são os slash commands. E um que acho que todo dev hoje precisa ter é o /commit. Ele acabou com um hábito que vários devs sofrem, até os mais experientes. O /commit deixa a régua explícita, e o time todo passa a escrever commits do mesmo jeito.

Sempre me importei com mensagens de commit. Mesmo dev que se importa acaba deixando um "fixes" ou um "update" genérico escapar numa sexta cansada ou no meio de um refactor gigante. É assim que um repo acaba com uma camada de ruído que ninguém decifra três meses depois.

O que é um slash command

Slash commands não são exclusivos do Claude Code. OpenCode, Codex CLI, Aider e Continue deixam você criar seus próprios comandos de algum jeito. O formato e o gatilho mudam, mas a ideia é a mesma: um atalho curto roda um prompt mais longo que você escreveu uma vez.

Vou mostrar com Claude Code, que é o que uso no dia a dia. A configuração se traduz bem pros outros.

No Claude Code, um slash command é só um arquivo markdown. Você joga ele em ~/.claude/commands/<nome>.md (global) ou .claude/commands/<nome>.md (por projeto), e pronto: /<nome> vira atalho. O frontmatter tem um description, e o corpo é o prompt que o agente lê quando você chama.

É isso. Sem DSL, sem SDK, sem manifesto de plugin. Arquivo markdown entra, slash command sai.

O problema do commit

Mesmo com um agente bom no loop, um simples "commita minhas mudanças" te entrega algo passável, mas não excelente. O agente escolhe um tipo qualquer, escreve uma mensagem que serve e empilha mudanças sem relação no mesmo commit. Melhor do que sem agente nenhum. Mas dá pra melhorar.

O que eu queria era algo que lesse minhas mudanças, agrupasse por domínio, escrevesse uma mensagem decente seguindo o Conventional Commits pra cada grupo, e pulasse os arquivos que não devem ser commitados.

/commit

Aqui vai o slash command que montei pra manter os commits limpos e consistentes:

---
description: "Analyze all changes and commit in logical groups."
---

# Commit

## Step 1: Survey changes

Run `bin/commit-survey` to get the file lists and classification.

Read diffs of key files if you need more context on the changes.

## Step 2: Group the changes

Use the `--- classified ---` output as a starting point, then refine into logical commits.

Grouping strategy:
- By domain/feature: e.g., all auth changes together
- By layer: e.g., model tests, controller tests
- By type: e.g., all config changes, all dependency updates

Files in `[skip]` should NOT be committed. If unsure about a file, skip it.

## Step 3: Commit each group

For each group, combine stage + commit in one call:

git add <specific files> && git commit -m "<message>"

Order commits from most independent to most dependent:
- Config/tooling changes first
- Then source code changes
- Then test changes
- Generated files last

Esses três passos são o motor inteiro.

bin/commit-survey

O Step 1 chama um script. É o que faz o resto funcionar.

Eu poderia pedir pro agente rodar git status, git diff, parsear a saída e classificar os arquivos na cabeça dele. Funcionaria na maioria das vezes. Mas aí cada execução gasta tokens na mesma lógica de parsing, e a saída fica do jeito que o Claude tiver inspirado naquele dia.

Um script Ruby curto te dá:

Uma invocação previsível
Menos tokens (sem saída de git status pra digerir, só o resultado classificado)
Buckets que batem com o jeito que você pensa no seu código

São ~22 linhas:

SKIP_PATTERNS = %w[.env credentials master.key tasks.md notes.txt scratch .claude/]

BUCKETS = {
  "skip"   => ->(path) { SKIP_PATTERNS.any? { |pat| path.include?(pat) } },
  "test"   => ->(path) { path.start_with?("test/") },
  "db"     => ->(path) { path.start_with?("db/") },
  "config" => ->(path) { path.start_with?("config/", "Gemfile", ".rubocop", "Procfile", "Rakefile") },
  "docs"   => ->(path) { path.start_with?("docs/", "README") || path.end_with?(".md") },
  "app"    => ->(_)     { true }
}

paths = `git status --porcelain`.lines(chomp: true).map { |l| l[3..] }
grouped = BUCKETS.keys.to_h { |b| [b, []] }
paths.each { |path| grouped[BUCKETS.find { |_, matcher| matcher.call(path) }.first] << path }

BUCKETS.each_key do |bucket|
  files = grouped[bucket]
  puts "[#{bucket}] #{files.empty? ? "(none)" : files.join(", ")}"
end

skip vem primeiro pra que segredos e notas nunca acabem staged. O resto é um buffet que você ajusta por projeto. Uma app Phoenix teria lib/, priv/repo/migrations/, assets/. Uma app Next.js teria pages/, app/, public/, prisma/. Mesma ideia, paths diferentes.

Roda num repo sujo e sai isso:

--- unstaged ---
 M config.toml
 M templates/index.html

--- untracked ---
content/blog/_index.md
content/blog/post.md

--- classified ---
[skip]   (none)
[test]   (none)
[db]     (none)
[config] config.toml
[docs]   content/blog/_index.md, content/blog/post.md
[app]    templates/index.html

O agente olha aquilo e escreve uns três commits: chore(config): bump zola version, feat(templates): add language toggle, feat(blog): bootstrap section. Três mensagens focadas em vez de uma pra cobrir tudo.

Na prática

Eu digito /commit e o Claude:

Roda bin/commit-survey e lê a saída
Lê diffs dos arquivos que precisar pra ter mais contexto
Stage + commit de cada grupo com mensagem Conventional Commits
Pula .env e qualquer segredo silenciosamente

A coisa toda leva 30 segundos, e cada commit sai limpo e bem escopado.

Exemplo real desse próprio blog. Survey antes do run:

[skip]   (none)
[test]   (none)
[db]     (none)
[config] config.toml
[docs]   content/blog/slash-commands-no-more-bad-commits.md, content/blog/slash-commands-no-more-bad-commits.pt-br.md
[app]    sass/_predefined.scss, sass/style.scss

O que o /commit produziu:

feat(blog): add slash commands post in EN and pt-br
chore(config): drop syntax theme, switch to monochrome code blocks
style(sass): apply osaka jade palette and bump body font

Três commits, cada um com escopo claro.

Faça o seu

O jeito mais simples de começar é copiar esse e ir ajustando. Joga o arquivo em ~/.claude/commands/commit.md se quiser global, ou em .claude/commands/commit.md por projeto. Ajusta os patterns dos buckets pro teu stack. Pronto.

Dá pra fazer a mesma coisa pra qualquer coisa que você faz toda hora: /changelog, /release, /pr-draft, /deploy. Cada um é um arquivo markdown com os passos que você teria que digitar no chat toda vez.

Finalizando

A configuração é pequena, mas a diferença aparece em todo commit. Um slash command customizado mais um script pequeno já é suficiente pra fazer a IA pegar o trabalho rotineiro pra si.

Chega de commits "update". Cada commit reflete a régua que você escreveu no arquivo markdown.

Fontes:

Publicado originalmente em guilherme44.com.

Sending SMS with Ruby and Twilio

Guilherme Yamakawa de Oliveira — Fri, 01 May 2026 03:27:11 +0000

I had never built an app that needed to send SMS, but our last project at the firm required it. I talked to a friend about it and he told me about Twilio. I did some quick research and found the docs really complete and easy to follow.

For those who don't know Twilio, it's a platform that lets you integrate voice, text messages, video, notifications and other things into your app through an API. Integrations are available in Ruby, Java, .NET, Node.js, PHP, and others.

I'll show how easy it is to send SMS from the Ruby console. Soon I plan to do a screencast on how to implement this in a Ruby on Rails app.

Step 1: Create a Twilio account

Create a Twilio account and access the Twilio Console.

Sign up: https://www.twilio.com/try-twilio

Console: http://twilio.com/console

When you create the account you get a Trial for running tests:

Don't forget to register a verified number.
https://www.twilio.com/console/phone-numbers/verified

Note: Verified numbers are required to send SMS in TRIAL mode.

Step 2: Send the SMS

Install the Twilio gem:

gem install twilio-ruby -v 5.21.2

Open a Ruby console:

irb

Inside the console we import the twilio-ruby gem, set up the variables and send a message.

require 'twilio-ruby'

# Get your SID and Auth Token from twilio.com/console
# DANGER! This is insecure.
account_sid = 'ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
auth_token = 'your_auth_token'
number = 'your_number' # Number you rented from twilio
@client = Twilio::REST::Client.new(account_sid, auth_token)

message = @client.messages.create(
  from: number, # +15017122661
  body: 'My first message sent with ruby.',
  to: '+5544999801281' # +5544998761234
)

puts message.sid

Keep in mind this is insecure. It's important to keep credentials like the SID and Auth Token stored in a way that prevents unauthorized access. Since this is just a test example, I used them straight in the console.

Wrapping up

As you can see, it's pretty easy to send SMS with Ruby.

Twilio offers many other services and you can check the pricing for all of them at https://www.twilio.com/pricing.

Originally posted at guilherme44.com.