<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blog on Ivens Signorini</title><link>https://signorini.cloud/en/blog/</link><description>Recent content in Blog on Ivens Signorini</description><generator>Hugo</generator><language>en-GB</language><lastBuildDate>Tue, 06 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://signorini.cloud/en/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>The evolution of Java: from 1.0 to 27, and the object header that shrank</title><link>https://signorini.cloud/en/blog/java-evolution-compact-object-headers/</link><pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate><guid>https://signorini.cloud/en/blog/java-evolution-compact-object-headers/</guid><description>&lt;p&gt;Java reached version 27 in September 2026, thirty years after JDK 1.0, and one of the most relevant changes in this release does not show up in any line of code: every object in the JVM now has, by default, an 8-byte header instead of a 12-byte one.&lt;/p&gt;&#10;&lt;p&gt;Two stories intersect here. One is the evolution of the language and the platform, release by release. The other is the object header: what it is, why it cost so much, and how Project Lilliput shrank it without breaking the JVM. Shrinking the header was only possible because, over several releases, the platform removed or rewrote old pieces that occupied those bits.&lt;/p&gt;</description></item><item><title>MCP Servers: the protocol that gave AI hands</title><link>https://signorini.cloud/en/blog/mcp-servers/</link><pubDate>Wed, 17 Jun 2026 00:00:00 +0000</pubDate><guid>https://signorini.cloud/en/blog/mcp-servers/</guid><description>&lt;p&gt;AI models are extraordinary at reasoning. They&amp;rsquo;re terrible at acting — or at least they were, until they had a standardized way to reach outside themselves. MCP is that way.&lt;/p&gt;&#10;&lt;h2 id="the-problem-before-mcp"&gt;The problem before MCP&lt;/h2&gt;&#10;&lt;p&gt;In 2023, if you wanted an LLM to read a file, query a database, or call an API, you wrote custom glue code. Every team reinvented the same wheel: a thin layer that serialized context, passed it to the model, parsed tool calls out of the response, executed them, and fed results back. There was no standard. Every integration was a one-off.&lt;/p&gt;</description></item><item><title>When the web isn't enough: the Wails bridge protocol</title><link>https://signorini.cloud/en/blog/when-the-web-isnt-enough-the-wails-bridge-protocol/</link><pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate><guid>https://signorini.cloud/en/blog/when-the-web-isnt-enough-the-wails-bridge-protocol/</guid><description>&lt;h2 id="the-web-won--except-where-it-didnt"&gt;The web won — except where it didn&amp;rsquo;t&lt;/h2&gt;&#10;&lt;p&gt;For most software, the browser is the right answer. A web app installs nothing, updates&#10;itself, runs on every OS, and lets you build the UI with the richest, best-tooled&#10;front-end ecosystem on earth. If you &lt;em&gt;can&lt;/em&gt; ship a web app, you usually should.&lt;/p&gt;&#10;&lt;p&gt;But the browser is a sandbox, and that sandbox has walls. They exist for good reasons —&#10;a random web page should not be able to read your microphone&amp;rsquo;s raw loopback stream, open&#10;arbitrary files, talk to a USB device, or run a tight numerical loop that pins a CPU core.&#10;The same restrictions that make the web safe to browse make it the wrong tool for a whole&#10;class of programs.&lt;/p&gt;</description></item><item><title>What distributed systems taught me about trade-offs</title><link>https://signorini.cloud/en/blog/on-distributed-systems/</link><pubDate>Wed, 20 May 2026 00:00:00 +0000</pubDate><guid>https://signorini.cloud/en/blog/on-distributed-systems/</guid><description>&lt;p&gt;Every distributed system is a negotiation. You&amp;rsquo;re not building a machine that always works — you&amp;rsquo;re deciding, deliberately, how it fails.&lt;/p&gt;&#10;&lt;h2 id="the-problem"&gt;The problem&lt;/h2&gt;&#10;&lt;p&gt;Engineers coming from single-node backgrounds tend to treat distribution as a deployment detail. You write your service, containerize it, scale it horizontally, and assume the behavior stays the same. It doesn&amp;rsquo;t. Network calls fail silently. Clocks drift. Nodes crash mid-write. The moment you have more than one machine, you have a system that can disagree with itself — and you need a position on what to do when it does.&lt;/p&gt;</description></item><item><title>Go interfaces: small is beautiful</title><link>https://signorini.cloud/en/blog/go-interfaces/</link><pubDate>Fri, 10 Apr 2026 00:00:00 +0000</pubDate><guid>https://signorini.cloud/en/blog/go-interfaces/</guid><description>&lt;p&gt;If you come from Java or C#, your instinct is to design big interfaces and have types implement them. Go inverts this completely — and that inversion is the point.&lt;/p&gt;&#10;&lt;h2 id="the-problem"&gt;The problem&lt;/h2&gt;&#10;&lt;p&gt;Most languages treat interfaces as contracts you declare up front. You define &lt;code&gt;interface IUserRepository&lt;/code&gt; with twelve methods, then every type that wants to be a repository must explicitly implement all twelve. The coupling is baked in at definition time, not at use time.&lt;/p&gt;</description></item></channel></rss>