iiinova — where your digital self keeps evolving

Moving slogbox to Go 1.27 made me revisit what the library promises when serializing logs and serving them over HTTP. Changing the version in go.mod was the easy part 😅.

000

I updated slogbox for Go 1.27 and JSON v2. I wrote about the migration decisions: what to preserve in the JSON output and how to handle errors after part of an HTTP response has already been sent. alexrios.me/blog/slogbox...

Updating slogbox for Go 1.27

A Go 1.27 upgrade exposed a JSON contract, an HTTP error-design flaw, and a benchmark that looked fast because it failed early

100

Na migração do slogbox para Go 1.27, precisei rever o que a biblioteca promete ao serializar logs e entregá-los por HTTP. Trocar a versão no go.mod foi a parte fácil 😅.

000

Atualizei o slogbox para Go 1.27 e JSON v2. Escrevi sobre as decisões da migração: o que preservar no JSON e como lidar com erros quando parte da resposta HTTP já foi enviada. alexrios.me/blog/slogbox...

Atualizando o slogbox para o Go 1.27

A atualização para Go 1.27 expôs um contrato JSON, uma falha no design de erros HTTP e um benchmark que parecia rápido porque falhava cedo

100

That's a good one! Thanks!

Alex Rios @alexrios.me · 27/09/2026

Hey Gophers, I need your help! What theme should I send to @gophercon.jp call for papers? I have only 2 submissions! Don't say Green Tea GC internals. It's the first one 🤓.

110

Alex Rios @alexrios.me · 18/09/2026

For more complex lifecycles, I'd use an explicit state machine to define allowed transitions and their guards. I'd still expose operations like publish() and archive(), with those rules enforced inside, though. For a handful of states, checks in those methods may be enough.

Alex Rios @alexrios.me · 15/09/2026

What transition, for instance? (Any that you have in mind)

100

Alex Rios @alexrios.me · 14/09/2026

A module can look encapsulated while another reaches straight into its state. I wrote about transparent boundaries, with a Go example that moves mutation back to its owner. alexrios.me/blog/patholo...

000

Alex Rios @alexrios.me · 14/09/2026

Continuando os posts sobre aspectos fundamentais de design 🌞 Nesse post, exploro as "fronteiras transparentes". alexrios.me/blog/patholo...

O encapsulamento que só existe na aparência

Fronteiras transparentes

000

Alex Rios @alexrios.me · 07/09/2026

In the post, I connect this to product and sum types, then work through a small Go implementation. I also cover zero values, parsing external data, and why valid states do not guarantee valid transitions. alexrios.me/blog/bool-fl...

Boolean flags and states that should not exist

From ambiguous boolean parameters to contradictory struct fields: make operations explicit and model only the states the domain allows.

Alex Rios @alexrios.me · 07/09/2026

The world tour continues relentlessly. I keep submitting talks and somehow people keep accepting them. Next stop: GoLab 2026, Bologna 🇮🇹 Talking about Green Tea GC, Go’s new garbage collector, and why “scan spans, not objects” turns out to be a much bigger idea than it first appears.

131

Alex Rios @alexrios.me · 07/09/2026

My slides from GopherCon LATAM 2026 are now available: 🇧🇷 PT-BR talks.alexrios.me/gc-latam-26-... 🇪🇸 ES talks.alexrios.me/gc-latam-26-... 🌎 EN talks.alexrios.me/gc-latam-26-... Hope they’re useful even if you couldn’t make it to the talk.

000

Reposted by Alex Rios

Konrad Reiche @konradreiche.com · 02/09/2026

Great talk from @alexrios.me on spin locks in Go at GopherCon Latam. They can outperform sync.Mutex, but only under a narrow set of conditions: a critical section under 100 ns, proven contention, multi-core deployment, and why Go generally favors safety, portability, and fairness over exposing them.

031

Alex Rios @alexrios.me · 22/08/2026

Tito Lívio diz que Roma reprimiu as Bacanais por assassinato, uso de veneno e fraude. O único documento oficial contemporâneo que sobreviveu não menciona nada disso. Ele fala de caixa, juramentos, cargos e reuniões. O que essa diferença revela?

100

Alex Rios @alexrios.me · 20/08/2026

Most Go design problems don't start with architecture. They start with a function accepting more than it needs. I shared thoughts about precise signatures, small interfaces, and why every parameter should be an honest contract. alexrios.me/blog/stamp-c...

Precision is the missing virtue in Go interfaces

Every parameter is a contract. Make it small enough to honor

000

Alex Rios @alexrios.me · 19/08/2026

Processo dá uma sensação poderosa de controle. Quando a org cresce, essa sensação pode virar uma armadilha: mais etapas, mais aprovações, mais rituais e mais governança começam a parecer uma resposta para problemas que, muitas vezes, são de contexto, autonomia, competência ou desenho da cia.

100

Cortar design aumenta o custo total de um projeto, como a cultura do MVP continua empurrando times pro lado mais caro da curva. Além disso, um pouco de o que “suficiente design” significa na prática. alexrios.me/blog/underbu...

Cortar design aumenta o custo total

Por que seu MVP continua levando dezoito meses

000

Times raramente pulam design porque não se importam. Pulam porque design parece custoso hoje, enquanto fazem debugging, retrabalho e dor operacional chegam aos poucos durante os próximos dezoito meses. Essa troca quase sempre sai cara 😅 .

Cortar design aumenta o custo total

Por que seu MVP continua levando dezoito meses

100

I wrote about why underbudgeting design increases a project's total cost, why "MVP culture" keeps choosing the expensive side of the curve, and what “enough design” looks like in practice. alexrios.me/blog/underbu...

Underbudgeting design increases total cost

Why your MVP keeps taking eighteen months

000

Teams rarely skip design because they do not care. They skip it because design looks expensive today, while debugging, rework, and operational pain arrive quietly over the next eighteen months. That trade is usually a bad one.

Underbudgeting design increases total cost

Why your MVP keeps taking eighteen months

100

That's also why heuristics age badly: they're yesterday's consensus about yesterday's problems. The problem shape doesn't move; the agreement about what "solves it" does.

The problem obeys physics; the solution obeys people, in a sense. Both concrete things in the universe 😁

100

Answering your question: Close, but not the same, I think. Your "first principles" map to my problem shape. But I wouldn't call the solution side "opinions", and those are real constraints, just human ones: what the group can understand, apply, and maintain.

100

A gente aprendeu a confundir confiança com competência. A WeWork chegou a valer US$ 47 bilhões porque Adam Neumann não vendia escritórios. Vendia certeza

100

In other words, heuristics is a function that have time as the main variable and the solution is trapped on the common agreement on "it solves the problem" by the people involved in the solution.

100

humm... I'm not really sure, but I see heuristics as a trend that tries to sew the problem space and solution with a cognitive shortcut, while the solution itself, even if it has its own constraints, is capped by the group's ability to understand, apply, and maintain it.

100

It makes total sense. Thanks for adding this!

I wrote about the five binding times, named by what each one actually costs to change. From "a code change in every copy" down to "a provider update". alexrios.me/blog/late-bi...

What does it take to change this?

Five binding times, named by what it costs to change them

000

"Should this be a constant or a config value?" "Should we use DI here or construct it inline?" Same question, dressed up: when does this identifier get its final value?

What does it take to change this?

Five binding times, named by what it costs to change them

100

Alex Rios @alexrios.me · 07/08/2026

We often call something a “heuristic” when, in practice, it’s just a way to avoid understanding the problem. When a solution starts accumulating exceptions, weights, thresholds, and special rules, maybe the problem isn’t the algorithm. Maybe it’s the structure we chose to represent the problem.