<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>&lt;thisisjab/&gt;</title><link>https://thisisjab.github.io/</link><description>Recent content on &lt;thisisjab/&gt;</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 14 Jun 2026 17:08:09 +0330</lastBuildDate><atom:link href="https://thisisjab.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>sync.Cond: an Underrated Gem</title><link>https://thisisjab.github.io/posts/go-sync-cond/</link><pubDate>Sun, 14 Jun 2026 17:08:09 +0330</pubDate><guid>https://thisisjab.github.io/posts/go-sync-cond/</guid><description>&lt;p&gt;Go&amp;rsquo;s standard library ships with an impressive set of tools for building concurrent applications. Most Go developers reach for channels, &lt;code&gt;sync.Mutex&lt;/code&gt;, or &lt;code&gt;sync.WaitGroup&lt;/code&gt; — and that covers the vast majority of use cases. But there&amp;rsquo;s one primitive that is underrated in my opinion: &lt;code&gt;sync.Cond&lt;/code&gt;.&lt;/p&gt;
&lt;h2 id="what-is-synccond"&gt;What Is sync.Cond?&lt;/h2&gt;
&lt;p&gt;Imagine you have a group of workers that need to coordinate before proceeding with a task. Your first instinct might be to use channels, and that&amp;rsquo;s usually the right call. But consider a scenario where goroutines need to sleep until a specific condition is met — say, a connection pool with a maximum of 10 open connections shared by 20 workers. You need workers to sleep when no connections are available and wake up only when one is freed, while also tracking other state variables simultaneously. In cases like these, relying solely on channels, mutexes, or wait groups can get awkward fast.&lt;/p&gt;</description></item><item><title>Redis Is More Than A In-Memory KV Database</title><link>https://thisisjab.github.io/posts/redis-is-great/</link><pubDate>Fri, 05 Jun 2026 17:26:43 +0330</pubDate><guid>https://thisisjab.github.io/posts/redis-is-great/</guid><description>&lt;p&gt;When it comes to Redis, everyone says: &amp;ldquo;Yeah, I use Redis for caching, and it&amp;rsquo;s great.&amp;rdquo;
But is this your highest perception of Redis? If you only use Redis for caching, then why not use Memcached?&lt;/p&gt;
&lt;p&gt;In this post, I will try to show that Redis is capable of so many things that make your engineering life way too easy.
In fact Redis is a masterpiece.&lt;/p&gt;
&lt;p&gt;&lt;img src="https://thisisjab.github.io/images/posts/redis-is-great.webp" alt="Redis"&gt;&lt;/p&gt;
&lt;h1 id="what-is-redis-btw"&gt;What is Redis, btw?&lt;/h1&gt;
&lt;p&gt;Redis is a key-value database that stores its data in memory. Therefore, it is extremely fast and memory efficient. It is also worth mentioning that Redis&amp;rsquo;s speed is not just about memory. Under the hood, Redis makes use of a number of different data structures to store and retrieve its data efficiently. I will try to cover a few of the life-saving data structures provided by Redis that have flown under the radar.&lt;/p&gt;</description></item><item><title>Everything is a transaction in PostgreSQL. So what?</title><link>https://thisisjab.github.io/posts/postgresql-mvcc/</link><pubDate>Mon, 25 May 2026 19:15:47 +0330</pubDate><guid>https://thisisjab.github.io/posts/postgresql-mvcc/</guid><description>&lt;p&gt;Every statement you run in PostgreSQL is inside a transaction, either explicitly or implicitly, and this may ring a bell. But let&amp;rsquo;s focus on this matter and see what is going on, as this single architectural choice dictates why, for example, your COUNT(*) queries are slow, why your database disk space mysteriously balloons, and why dead rows might be haunting your storage.&lt;/p&gt;
&lt;h1 id="the-question"&gt;The question&lt;/h1&gt;
&lt;p&gt;First, I&amp;rsquo;d like to draw your attention to this section of PostgreSQL&amp;rsquo;s official documentation on transactions.&lt;/p&gt;</description></item><item><title>About me</title><link>https://thisisjab.github.io/about/</link><pubDate>Tue, 17 Feb 2026 22:45:30 +0330</pubDate><guid>https://thisisjab.github.io/about/</guid><description>&lt;p&gt;Hey! I am Jab (M. Hossein Jabbarzadeh to be precise). Welcome to my corner of the internet. I’m a final-year Computer Engineering student and a backend engineer with three years of professional experience. This blog is my digital workbench — a place where I document academic deep dives, real-world engineering challenges, and the &amp;ldquo;geeky stuff&amp;rdquo; that keeps me up at night.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="who-i-am"&gt;Who I Am&lt;/h2&gt;
&lt;p&gt;I’m a builder at heart. For me, computers have been the most fascinating &amp;ldquo;toy&amp;rdquo; since childhood, and that curiosity hasn&amp;rsquo;t faded. I want to understand how they work in every aspect: operating systems, networks, and hardware.&lt;/p&gt;</description></item><item><title>Hello, friend!</title><link>https://thisisjab.github.io/posts/hello-friend/</link><pubDate>Tue, 17 Feb 2026 22:42:28 +0330</pubDate><guid>https://thisisjab.github.io/posts/hello-friend/</guid><description>&lt;p&gt;Hi, friend. (With Elliot Alderson&amp;rsquo;s tone). This is my first writing that I am posting on my corner of the internet—my so-called weblog.&lt;/p&gt;
&lt;p&gt;The idea of starting a blog—writing in general—has always occurred to me. I believe writing is one of the most precious tools ever built by mankind. To me, it feels old, but never outdated. Furthermore, I am tired of this dopamine burst we’re forced through every day. We’ve traded our focus for 15-second loops. Nowadays, people cannot focus for more than 40 seconds (&lt;a href="https://www.nationalgeographic.com/health/article/attention-spans-shrinking-how-to-regain"&gt;according to this article&lt;/a&gt;) as our attention spans have shrunk due to excessive use of shorts and reels. Machine learning algorithms have evolved to do one thing: keep you scrolling through (all most) junk until your brain rots.&lt;/p&gt;</description></item></channel></rss>