<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Push to Mastery</title><link>https://pessolato.github.io/</link><description>Recent content on Push to Mastery</description><generator>Hugo</generator><language>en</language><copyright>&lt;a href='https://creativecommons.org/licenses/by-nc/4.0/' target='_blank' rel='noopener'>CC BY-NC 4.0&lt;/a></copyright><lastBuildDate>Sun, 21 Sep 2025 12:58:36 +0200</lastBuildDate><atom:link href="https://pessolato.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Go HTTP: Impact of NOT Reading Response Bodies to EOF</title><link>https://pessolato.github.io/posts/go-http-drain-close-microbench/</link><pubDate>Sun, 21 Sep 2025 12:58:36 +0200</pubDate><guid>https://pessolato.github.io/posts/go-http-drain-close-microbench/</guid><description>&lt;p>Recently, a colleague and I were discussing whether draining the response body (my shorthand for “reading to EOF before closing”) was actually necessary when the response contains an error code. In that situation, the client already reads the full body on successful requests, so my colleague argued that skipping the drain on error responses would have negligible performance impact.&lt;/p>
&lt;p>That reasoning made sense at first glance, but it left me curious. I knew the theory, but I wanted to quantify the actual performance impact of not draining response bodies.&lt;/p></description></item><item><title>The Importance of MFA and some misconceptions</title><link>https://pessolato.github.io/posts/mfa-misconceptions/</link><pubDate>Tue, 22 Jul 2025 20:57:48 +0200</pubDate><guid>https://pessolato.github.io/posts/mfa-misconceptions/</guid><description>&lt;p>When discussing the security of information systems, one of the foundational concepts is &lt;strong>authentication&lt;/strong>, which can be defined as the process of verifying the identity of a user, device, or system attempting to access a resource. Authentication answers the question: &lt;em>“Who are you?”&lt;/em>, and it does so by requiring evidence of identity.&lt;/p>
&lt;p>This verification is necessary because, much like in physical security, access to protected spaces or resources must be controlled based on evidence of identity. In the physical world, guards at a secure facility do not simply allow anyone to enter; they check badges, keys, or biometric features, and may even recognize familiar individuals. The possession of a key or ID, knowledge of a code, or inherent physical traits serve as tangible proofs of identity. Similarly, in digital systems, where there is no direct way for the system to “see” or “sense” the claimant, we rely on analogous mechanisms: transmitted credentials and controlled challenges that emulate the same principles of trust established at a physical checkpoint.&lt;/p></description></item><item><title>Microbenchmarking Go: Bytes vs. Runes and the Hidden Cost of Map Keys</title><link>https://pessolato.github.io/posts/go-str-map-microbench/</link><pubDate>Sun, 22 Jun 2025 15:03:36 +0200</pubDate><guid>https://pessolato.github.io/posts/go-str-map-microbench/</guid><description>&lt;p>While working through the &lt;a href="https://exercism.org/tracks/go">Go track on Exercism.org&lt;/a>, I ran into an interesting performance puzzle in the &lt;strong>Nucleotide Count&lt;/strong> exercise. It looked simple at first glance, but it sent me down a rabbit hole of microbenchmarking that revealed an insight beyond just how you iterate over strings.&lt;/p>
&lt;h2 id="the-initial-question-bytes-or-runes">The Initial Question: Bytes or Runes?&lt;/h2>
&lt;p>The input is a DNA sequence, which contain only ASCII characters like &lt;code>A&lt;/code>, &lt;code>C&lt;/code>, &lt;code>G&lt;/code>, and &lt;code>T&lt;/code>. Naturally, I reached for a &lt;code>map&lt;/code> to count each nucleotide.&lt;/p></description></item></channel></rss>