<?xml-stylesheet type="text/css" href="/assets/css/feed.css"?> <feed xmlns="http://www.w3.org/2005/Atom"><html:div xmlns:html="http://www.w3.org/1999/xhtml" class="about-feed"><html:p><html:strong>This is the web feed for Gems of Coding.</html:strong> To follow new posts, copy this page's address into a feed reader.</html:p><html:p><html:a href="/">← Back to the blog</html:a></html:p> </html:div> <id>https://gemsofcoding.com/</id><title>Gems of Coding</title><subtitle>A tech blog by Tisan Das — notes on distributed systems, databases, system design, algorithms, security and deep learning.</subtitle> <updated>2026-10-20T13:07:40+05:30</updated> <author> <name>Tisan Das</name> <uri>https://gemsofcoding.com/</uri> </author><link rel="self" type="application/atom+xml" href="https://gemsofcoding.com/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://gemsofcoding.com/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Tisan Das </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>PostgreSQL - Why Isolation Levels Behave the Way They Do</title><link href="https://gemsofcoding.com/Postgres-Isolation-Fundamentals/" rel="alternate" type="text/html" title="PostgreSQL - Why Isolation Levels Behave the Way They Do" /><published>2026-10-20T01:00:00+05:30</published> <updated>2026-10-20T01:00:00+05:30</updated> <id>https://gemsofcoding.com/Postgres-Isolation-Fundamentals/</id> <content type="text/html" src="https://gemsofcoding.com/Postgres-Isolation-Fundamentals/" /> <author> <name>Tisan Das</name> </author> <category term="Databases" /> <category term="PostgreSQL" /> <summary>When two transactions work on the same data at the same time, PostgreSQL has to answer two questions: what is each transaction allowed to see, and what happens when both try to change the same row? The isolation level decides the answers. Postgres has three levels that behave differently: READ COMMITTED, the default; REPEATABLE READ; and SERIALIZABLE, the strictest. Most explanations teach the...</summary> </entry> <entry><title>TLA+ and PlusCal from First Principles</title><link href="https://gemsofcoding.com/TLA-Plus-And-PlusCal-From-First-Principles/" rel="alternate" type="text/html" title="TLA+ and PlusCal from First Principles" /><published>2026-10-16T09:00:00+05:30</published> <updated>2026-10-16T09:00:00+05:30</updated> <id>https://gemsofcoding.com/TLA-Plus-And-PlusCal-From-First-Principles/</id> <content type="text/html" src="https://gemsofcoding.com/TLA-Plus-And-PlusCal-From-First-Principles/" /> <author> <name>Tisan Das</name> </author> <category term="Distributed Systems" /> <category term="Formal Methods" /> <summary>Many programmers learn TLA+ through PlusCal, with a model checker that keeps telling them they’re wrong. The syntax is never the hard part. What takes time is the meaning underneath it. What exactly is a “step”? Why do labels decide what’s atomic? Why is CHOOSE not “pick any value”? How can a property hold in every single state and still be violated? And why does TLA+ make you write [][x&apos; &gt;= x]...</summary> </entry> <entry><title>Low-Level Design: Class Relationships and Design Patterns in Go and Python</title><link href="https://gemsofcoding.com/Low-Level-Design/" rel="alternate" type="text/html" title="Low-Level Design: Class Relationships and Design Patterns in Go and Python" /><published>2026-10-09T09:00:00+05:30</published> <updated>2026-10-19T23:26:52+05:30</updated> <id>https://gemsofcoding.com/Low-Level-Design/</id> <content type="text/html" src="https://gemsofcoding.com/Low-Level-Design/" /> <author> <name>Tisan Das</name> </author> <category term="Programming" /> <category term="Low-Level Design" /> <summary>Low-level design rests on two skills: telling how two classes are related, and recognizing design patterns, which are those same relationships arranged on purpose to solve a problem that keeps coming back. This post consists of six parts. Part 1 and Part 2 cover relationships, with 100 practice questions. Parts 3 to 5 (creational, structural, behavioral) cover the patterns, each with a class di...</summary> </entry> <entry><title>Inference Engineering - Part 6: Diffusion, and What Ties It Together</title><link href="https://gemsofcoding.com/Inference-Engineering-Diffusion-And-What-Ties-It-Together/" rel="alternate" type="text/html" title="Inference Engineering - Part 6: Diffusion, and What Ties It Together" /><published>2026-10-02T17:00:00+05:30</published> <updated>2026-10-02T17:00:00+05:30</updated> <id>https://gemsofcoding.com/Inference-Engineering-Diffusion-And-What-Ties-It-Together/</id> <content type="text/html" src="https://gemsofcoding.com/Inference-Engineering-Diffusion-And-What-Ties-It-Together/" /> <author> <name>Tisan Das</name> </author> <category term="LLM" /> <category term="Inference" /> <summary>Every earlier part of this series assumed autoregressive generation: the model writes one token at a time, left to right, and each token depends on all the ones before it. Part 3 showed what enforces that: the causal mask, which is also the only reason the key-value (KV) cache works. This final part looks at another alternative to autoregressive models, called diffusion language models, and the...</summary> </entry> <entry><title>Inference Engineering - Part 5: Sampling, From the API Down to the Bits</title><link href="https://gemsofcoding.com/Inference-Engineering-Sampling-From-The-API-To-The-Bits/" rel="alternate" type="text/html" title="Inference Engineering - Part 5: Sampling, From the API Down to the Bits" /><published>2026-10-02T00:00:00+05:30</published> <updated>2026-10-02T00:00:00+05:30</updated> <id>https://gemsofcoding.com/Inference-Engineering-Sampling-From-The-API-To-The-Bits/</id> <content type="text/html" src="https://gemsofcoding.com/Inference-Engineering-Sampling-From-The-API-To-The-Bits/" /> <author> <name>Tisan Das</name> </author> <category term="LLM" /> <category term="Inference" /> <summary>Three parameters sit between a trained model and its output: temperature, top_k and top_p. They are widely used and rarely defined precisely. All three act at the same instant and do the same job. The model has already run all of its layers and produced a score for every token in its vocabulary. These parameters act only on those final scores, after the model is done, to decide which token come...</summary> </entry> </feed>
