DEV Community: Michael N.

Secrets and Keys: The History of Encryption

Michael N. — Sat, 27 Sep 2025 08:00:00 +0000

Encryption has been with us for thousands of years. That sounds dramatic, but it’s true. Long before we had computers, Wi-Fi, or even electricity, humans were trying to keep secrets safe. Kings, generals, traders, and even lovers wanted ways to pass messages that no outsider could understand.

When we talk about encryption today, people often imagine algorithms with names like AES, RSA, or elliptic curves. But those are just the latest steps in a very long story. The story goes from leather straps in ancient Greece, to mechanical boxes in the Second World War, to the kind of code running invisibly on your phone right now, and maybe soon into the world of quantum computing.

In this piece, I don’t just want to “explain encryption” in the technical sense. I want to walk through its history, its purpose, and its future in a way that feels less like a lecture and more like a discussion. Along the way, I’ll use one of my own side projects, QR Crypt, which I built using Google’s AI Studio as a small example of how old ideas can find new forms.

So let’s start at the beginning.

Early Attempts at Hiding Messages

If you roll history all the way back, you’ll find people coming up with surprisingly clever tricks. One of the earliest examples comes from ancient Greece: the scytale cypher. It was just a leather strap wound around a stick. A general would write a message along the strap, then unwind it. Once unwound, the letters looked scrambled. Only someone with a stick of the same diameter could wrap the leather back up and read the original message.

Simple? Yes. Effective for its time? Also yes.

Fast forward a bit, and you’ll find Julius Caesar’s cypher, which is almost legendary now. Caesar would shift letters by a fixed number, maybe 3 places forward, so that “HELLO” would become “KHOOR.” Anyone intercepting it without knowing the rule would see gibberish.

From there, more sophisticated systems appeared, like the Vigenère cypher in the 1500s, which used repeating keys and felt “unbreakable” for a couple of centuries. (Spoiler: eventually, mathematicians figured it out.)

What’s worth noticing here is that these early systems weren’t “mathematically perfect.” They were clever enough to last until someone smarter or more determined came along. That theme repeats over and over in the history of encryption: it’s always an arms race.

Enigma and Friends

Now, let’s jump to the 20th century. Wars tend to accelerate technology, and World War II pushed cryptography forward in dramatic ways.

The most famous device from that era is the Enigma machine, used by Nazi Germany. It looked like a typewriter but had rotors inside that scrambled messages in complex ways. Each keypress would pass through multiple electrical paths, shifting with every press, making the output look random.

The brilliance of Enigma was its complexity. The flaw was that complexity still had patterns, and the Allies, with help from brilliant people like Alan Turing, eventually cracked it. That wasn’t just a victory of math; it was a victory that shortened the war.

The mechanical era showed that encryption wasn’t just an intellectual exercise. It was life and death, nations against nations, with machines and people racing to outsmart one another.

The Digital Revolution: From Cyphers to Code

Once computers entered the scene, encryption leapt into the digital realm. Instead of mechanical rotors, we now had algorithmic instructions that computers could follow at incredible speeds.

One of the early milestones here was RSA, created in the 1970s. Before RSA, most encryption was symmetric: the same key was used to both lock and unlock the message. That worked fine in small groups, but it was impractical on a global scale. How do you securely share the key in the first place?

RSA solved this with asymmetric encryption. It gave you two keys: a public key (which anyone can see and use to encrypt a message for you) and a private key (which only you hold and can use to decrypt). That single idea, two keys, mathematically linked but impossible to derive from one another, changed the world. It made online banking possible, digital signatures possible, and eventually the secure web as we know it.

Other algorithms followed. AES (Advanced Encryption Standard) became the backbone of symmetric encryption. Elliptic curve cryptography (ECC) offered efficiency with shorter keys. Each step forward made things harder to break and more practical to deploy.

What Makes Encryption “Unbreakable”?

At its core, encryption relies on math problems that are hard to solve.

RSA relies on the difficulty of factoring very large numbers.
ECC relies on the difficulty of solving certain problems on elliptic curves.
AES relies on transformations that resist all known shortcuts.

“Unbreakable” in practice doesn’t mean impossible forever. It means: impossible with the computing power and math knowledge we currently have. Every breakthrough in math or hardware shifts the balance.

QR Crypt: A Personal Example

When I was tinkering with Google’s AI Studio, I ended up building a small project called QR Crypt. The idea was simple: take a secret message, encrypt it with an XOR cypher and a key, and then turn it into a QR code.

Why a QR code? Because it’s an easy way to move data visually. You can print it, send it as an image, or even scrawl it on a napkin if you want. The catch: the QR code on its own is useless without the right key.

The fun part of building QR Crypt wasn’t “inventing” a new cypher (XOR has been around forever). It was combining:

A very old technique (XOR encryption).
A modern format (QR codes).
A no-server, privacy-first approach (everything happens in the browser).

It was also a great learning exercise. Working with AI Studio sped up the process, generating some boilerplate, suggesting improvements, and generally keeping the development flow light. But the important part for me wasn’t just building the tool; it was realising how encryption ideas echo through time.

From Caesar’s simple shifts to my little web app, the spirit is the same: how do you keep a message safe, and how do you control who gets to read it?

The above QR Code contains a secret message. Here is the key:

=aW5B(.:@!_tf!A>KUT*$R5o;,v!zdg^[ncl[bpsi]qq}Hxf-_WSG]q885Ra

Decrypt It Here!

Encryption in Everyday Life

Sometimes people treat encryption like it’s this shadowy thing only hackers or spies care about. In reality, you use it every single day, often without realising it.

When you see “https://” in your browser, that’s encryption at work (TLS, which uses asymmetric + symmetric algorithms together).
When you send a message on WhatsApp or Signal, it’s encrypted end-to-end.
When your phone unlocks with Face ID or a PIN, the stored biometric data is encrypted.

Without encryption, most of the modern internet would collapse. Passwords would leak, bank transfers would be unsafe, and private chats would be public.

Quantum Storms on the Horizon

Now let’s look ahead. What happens when quantum computers mature?

Quantum computing threatens many current encryption schemes. Why? Because certain problems that are “hard” for classical computers (like factoring large numbers for RSA) could become much easier with quantum algorithms like Shor’s.

That doesn’t mean the world is about to fall apart. Researchers are already working on post-quantum cryptography, designing algorithms resistant to both classical and quantum attacks. NIST (the U.S. National Institute of Standards and Technology) has even been running competitions to standardise new methods.

The shift to quantum-safe encryption will probably be slow but steady, like past upgrades. But it underscores the same point as always: encryption is never finished. It’s a living field, constantly adapting to new realities.

From leather straps in ancient Greece to AI-assisted side projects like QR Crypt, the thread is clear: humans have always cared about protecting information. Encryption evolves with us. It mirrors our fears, our creativity, and our technology.

I think what excites me most is that encryption isn’t just about secrecy. It’s about trust. It’s the thing that lets you type your credit card into a website, or whisper something to a friend over the internet, and feel confident that the message won’t be hijacked along the way.

And sometimes, encryption is just fun. Hiding a birthday wish inside a QR code. Building a browser toy to see how XOR feels in practice. Using Google’s AI Studio, not because you had to, but because it made exploration faster.

Encryption is serious business, yes. But it’s also a playground. And if history tells us anything, it’s that the playground will keep changing from Caesar’s alphabet shifts, to Enigma’s rotors, to RSA’s prime numbers, and one day, to post-quantum math we haven’t even dreamed up yet.

That’s the real magic of encryption: it’s both ancient and unfinished.

BedTales: AI-Powered Bedtime Storytelling for Families

Michael N. — Mon, 15 Sep 2025 05:07:57 +0000

This is a submission for the Google AI Studio Multimodal Challenge

BedTales: AI-Powered Bedtime Storytelling for Families

What I Built

I built BedTales, a storytelling applet that brings back the tradition of bedtime stories with the power of AI.

For thousands of years, storytelling has been how parents pass wisdom, morals, and imagination to their children. BedTales reimagines this timeless tradition by helping parents and kids co-create magical bedtime stories — complete with illustrations, voices, and saved characters — in just a few taps or even by speaking out loud.

BedTales isn’t just about reading stories; it’s about sparking imagination, encouraging creativity, and making bedtime an experience families look forward to.

Key Features:

AI Story Generation: Unique stories crafted from user prompts (character, setting, plot, concept).
AI Illustration: Each paragraph gets its own matching AI-generated artwork.
Character Creation: Save custom characters with portraits and reuse them across stories.
Voice-to-Prompt: Speak a story idea, and the AI structures it automatically.
Library & History: Save stories, track history, and revisit favorite tales.
Customization: Choose fonts, themes, and layouts to make the reading experience personal.
Data Portability: Export and share stories or entire libraries as JSON files.

The result is an offline-first Progressive Web App (PWA) that runs seamlessly on mobile, tablet, or desktop.

Demo

👉 [Deployed Applet Link]: Pending Due to Cloud Run Card Verification Issues
👉 [Ai Studio Link]: https://ai.studio/apps/drive/1kbom6wMNcX9viSeW3RBlTvYH-lnQGuuo

📸 Screenshots:

How I Used Google AI Studio

BedTales is powered by Google Gemini models inside Google AI Studio. Each core feature of the app is mapped to a specific multimodal capability:

Gemini 2.5 Flash → Generates story text, titles, structured prompts, and transcribes audio inputs.
Imagen → Creates unique illustrations for each story paragraph and character portrait.
Gemini Flash + Audio Input → Converts voice into structured prompts for characters or full story ideas.

All services are orchestrated in geminiService.ts and deployed with Cloud Run for scalability and simplicity.

Multimodal Features

The app combines text, audio, and images in a way that enhances storytelling:

Voice-to-Story: Kids or parents can simply speak an idea, and BedTales turns it into a structured bedtime story.
Text + Image Pairing: Each paragraph comes with a tailored illustration, turning reading into an immersive experience.
Character Consistency: Reference images are supported, so characters look the same across multiple stories.

This blend of modalities transforms storytelling from static text into a dynamic, visual, and auditory adventure — keeping children engaged and making family time more memorable.

The Discreet Lives of Apps

Michael N. — Thu, 04 Sep 2025 21:37:07 +0000

Ever wonder how your phone streams Netflix, checks email, refreshes social media, and syncs your weather app—all at the same time—without mixing everything up? It feels like magic. But under the hood, your operating system is quietly running a well-organized show with something called ports.

Think of apps like secret agents living in the same embassy (your phone). Every time they “phone home” across the internet, they need a unique badge number that proves who they are. That badge number? It’s the port.

1. The Secret Identities of Your Apps

When an app sends data out into the internet, it doesn’t just say, “Hey, I’m Instagram!” Instead, it uses a port number, like 80 or 443, to signal how the data should be handled.

Port 80: the old-school door for unencrypted web traffic (HTTP).
Port 443: the secure, encrypted door for HTTPS traffic.

Without ports, it would be like a hundred spies all whispering in the same room—pure chaos. With ports, everyone knows whose message is whose.

📌 Fun Facts

Port 443 handles over 80% of all web traffic today—that’s like being the busiest checkout lane in a store that never closes.
Tech culture nicknames ports too: Port 666 is sometimes called “doom” (after the video game), and 1337 spells leet in hacker speak.

2. The OS: Master Connection Handler

Behind the curtain, your operating system (OS) is the spymaster. It hands out ports, tracks who’s using what, and makes sure your Netflix stream doesn’t collide with your WhatsApp call.

This coordination happens through sockets—temporary pipelines that connect apps to the network.

Imagine the OS as a phone operator in the 1950s, manually plugging cables into switchboards. Only today, the switchboard is digital, lightning-fast, and juggling thousands of lines at once.

📌 Fun Facts

Your phone can theoretically handle 65,000+ simultaneous connections—basically, holding a conversation with an entire stadium of people.
Even in normal use, your phone might juggle 50–100 ports just for background refreshes, social media, and emails.

3. Why Port 443 Took Over the Internet

Port 443 isn’t just another door; it’s the secure door. It became popular because it supports SSL/TLS encryption, the tech behind HTTPS.

Why does that matter? Well, the difference between browsing over Port 80 (HTTP) and Port 443 (HTTPS) is like whispering your bank password loudly in public versus using a sealed envelope with your name on it.

📌 Fun Facts

The “s” in https:// was such a game-changer that Google actually ranks HTTPS sites higher in search results.
Today, Netflix alone probably generates more 443 traffic in a day than the entire internet did in 1995.

4. Ephemeral Ports: The Mall Parking Spaces

Here’s where things get clever. Your phone doesn’t just use ports like 80 and 443. It also creates temporary ports, called ephemeral ports, to handle unique conversations.

Think of them as parking spots in a busy shopping mall. You drive in, park for a while, leave, and the spot becomes available for someone else.

So when your browser connects to https://example.com on port 443, your OS might assign your app a temporary local port (say, 49152). The site knows you by this parking spot, while the OS ensures you don’t collide with another app’s connection.

📌 Fun Facts

Your computer can create and destroy thousands of ephemeral ports per minute without you noticing.
It’s one of the quietest but most important juggling acts your device performs.

5. Local vs. Internet Ports: What’s the Difference?

Not all ports are global superstars like 80 and 443. Some are local ports, used by developers and apps running just on your machine.

For example:

8080: A common “backup” web port, often used for local testing.
5555: Frequently used by Android devices for debugging.
25565: Used by Minecraft servers so friends can connect.

These local ports are like service entrances in a building—different from the front doors (like 80 and 443) that face the internet. They help apps communicate internally or set up test servers without colliding with the main network highways.

📌 Fun Facts

Port 8080 is so common it’s basically the internet’s “Plan B” when 80 is busy.
Gamers literally “open ports” to create digital doorways for friends to join matches.

6. Why All This Matters

From your perspective, it’s seamless. You just tap Instagram, join a Zoom call, or watch Netflix, and it all “just works.” But under the hood, your OS is running a high-stakes logistics game: handing out ports, securing them, and reusing them efficiently.

And while it feels invisible, understanding ports is the first step to understanding how the internet truly works—and why security and efficiency go hand in hand.

📌 Bonus Fun Facts

Hackers often scan for open ports like burglars checking for unlocked windows—that’s why firewalls are critical.
If Port 443 traffic were a highway, it would need about 50 lanes to handle rush-hour internet traffic.

Want to Learn More?

The Chadstrum: Rethinking Compiled vs Interpreted Languages

Michael N. — Sun, 31 Aug 2025 21:44:15 +0000

Our Obsession With Making Code “Understandable”

Humans have always struggled with translation. From carving symbols into clay to inventing alphabets, we’ve needed bridges between ideas and expression. Computers are no different. They only “speak” in binary: 1s and 0s. But since nobody wants to write 01101000 01101001 every time they mean “hi”, we invented programming languages.

Compilers and interpreters became the translators, standing between human-friendly languages and machine code. Just like a translator at the UN, they can either prepare a full translated speech in advance (compiled) or whisper line by line into the listener’s ear (interpreted). Both approaches have tradeoffs.

Where Did This Classification Even Come From?

The distinction between compiled and interpreted didn’t come out of thin air. In the 1950s, FORTRAN (Formula Translation) popularised the compiled model: code written once, translated into efficient machine instructions, then executed quickly. It was perfect for scientific calculations where speed mattered.

On the other side, Lisp and other early languages leaned more toward interpretation. They allowed programmers to test code interactively, line by line — a revolutionary idea at the time. Debugging became less of a nightmare because you didn’t need to recompile an entire program to try something new.

Back then, this divide mattered. Hardware was expensive, memory was scarce, and efficiency could make or break a project. Today, though, with more powerful machines and better tooling, the sharpness of this classification has blurred.

What We Mean by “Compiled”

When we call a language “compiled,” we mean that the source code is fully translated into machine code ahead of time. This produces an executable that runs directly on the CPU without needing the original source or an interpreter.

Performance: Fast execution, because all translation work is already done.
Error Checking: Many bugs surface during compilation.
Portability: Limited, since the binary only works on the target system.

Examples: C, C++, Rust, Go.

What We Mean by “Interpreted”

An interpreted language, on the other hand, reads and executes code line by line at runtime. The interpreter acts like a middleman every time the program runs.

Performance: Slower, because translation happens on the fly.
Error Checking: Bugs only appear at runtime.
Portability: High, since the same source can run anywhere with the right interpreter.

Examples: Python, JavaScript, Ruby, PHP

Enter the Grey Zone

Most modern languages don’t live in either extreme. They combine approaches:

Bytecode + VM: Java compiles source into portable bytecode, then executes it with the JVM.
JIT (Just-in-Time): JavaScript engines like V8 start interpreting but compile hot code into machine instructions on the fly.
AOT (Ahead-of-Time): Some environments pre-compile bytecode to native binaries for faster startup.

So, when we casually say “Python is interpreted” or “C is compiled,” we’re simplifying a much messier reality.

Introducing the Chadstrum

To make sense of this, I started thinking of it as a spectrum instead of a binary. I jokingly call it the Chadstrum:

On the far interpreted end, you’ve got languages like Bash or early Perl.
In the middle, there’s Java, C#, and modern JavaScript, which use VMs and JIT compilers.
On the far compiled end, you’ll find C, C++, Rust — where code is turned straight into machine instructions.

The point? Whether you’re coding in Bash scripts or writing kernel modules in C, you’re still a Chad. Both ends of the spectrum require skill, and both lead to powerful software.

Why This Still Matters Today

The compiled vs interpreted discussion may seem outdated, but it affects how we build and use software:

Performance: High-frequency trading software? Compiled. A quick automation script? Interpreted.
Portability: Java’s “write once, run anywhere” VM model vs. compiled binaries tied to a specific OS.
Developer Convenience: Interpreted languages let you prototype and experiment fast. Compiled ones catch errors early and scale better for performance-critical tasks.

But the bigger lesson? You don’t need to join language wars. The Chadstrum shows it’s not about being “better” — it’s about choosing the right tool for the job. At the end of the day, whether your code is compiled, interpreted, or something in between, it’s still getting the job done.

The world of programming languages isn’t black and white. It’s a messy, fascinating spectrum shaped by decades of history, performance needs, and human creativity.

The Bird that Wrote an Algorithm.

Michael N. — Mon, 25 Aug 2025 15:30:00 +0000

Ever heard of a bird inspiring a computer science algorithm? Yep, you read that right. Today we’re diving into Cuckoo Hashing, a powerful hashing technique that takes its inspiration straight from nature.

🐣 A Quick Story About Cuckoo Birds

Cuckoo birds are… jerks. Instead of building their own nests, they sneak their eggs into other birds’ nests. When the chick hatches, it kicks the others out and claims the nest all to itself. Bold move, right?

That same “move in and push the other out” trick is exactly how cuckoo hashing handles collisions in hash tables. It’s nature + computer science = genius.

📦 First, What’s a Hash Table Again?

A hash table is like a super-fast digital filing cabinet where you drop data in and retrieve it in almost constant time. If you’re new to hash tables, check out my earlier breakdown 👉 What is a Hash Table?

Hash tables are amazing, but they have one problem: collisions. That’s when two keys end up mapped to the same slot. Normally, we fix this with chaining or linear probing… but those methods can get messy.

Enter cuckoo hashing. 🐦✨

🐦💥 What Makes Cuckoo Hashing So Special?

Instead of giving each key just one slot, cuckoo hashing uses two different hash functions. That means each key has two possible homes.

Here’s the magic:

If one spot is full, the new key boots out the old resident (just like a cuckoo chick).
The displaced key then moves to its other possible home.
If that’s also full, the cycle repeats until everything finds a nest.

👉 Want to see cuckoo hashing in action? Play around with this awesome app, I made using AI Cuckoo Hashing Visualizer.

🧑‍💻 Pseudo Code: Cuckoo Hashing in Action

Here’s a simple version of the insert logic, written in easy-to-read pseudo code:

// Insert a key into the cuckoo hash table
function insert(key):
    for i = 1 to MaxAttempts:
        // Try first home
        if table1[h1(key)] is empty:
            place key in table1[h1(key)]
            return success

        // If not empty, evict the old resident
        swap key with table1[h1(key)]

        // Try second home
        if table2[h2(key)] is empty:
            place key in table2[h2(key)]
            return success

        // If not empty, evict the old resident again
        swap key with table2[h2(key)]
        // and repeat the loop with the evicted key

    // If we’ve tried too many times, the table is probably too full
    resize_and_rehash()

🔑 Key things to notice:

Each key has two homes.
If both are busy, the current resident gets kicked out.
After too many kicks, the table needs to resize and rehashed.

This simple loop is the heart of cuckoo hashing.

⏱️ Time Complexity: How Fast Is It Really?

Lookup → O(1). You only check up to 2 spots.
Insert → O(1) on average, though sometimes you shuffle a few items.
Delete → O(1). Just clear the spot.

Worst case? A cycle forms (items keep kicking each other around endlessly). That’s when you resize and rehash the whole table.

📜 A Little History: The Creators of Cuckoo Hashing

Cuckoo hashing was introduced in 2001 by Rasmus Pagh and Flemming Friche Rodler. Their goal? A hash table with constant-time lookups and clean structure — no messy chains or long probing sequences.

Whenever you need predictable O(1) lookups and can afford a little shuffle during insertions, cuckoo hashing is your friend.

The Art of Mocking in Backend Tests

Michael N. — Mon, 04 Aug 2025 09:00:00 +0000

One thing that hits you fast when you're building anything beyond to-do apps is this: testing matters. That “everything works on my machine” feeling? Doesn’t mean a thing in production.

But here's the thing... testing real dependencies in every test? That’s a pain. Slow tests. External services failing. APIs rate-limiting you. And now your tests are flaky, annoying, and worst of all, unreliable.

That’s where mocks come in like the chill friend that helps you focus on your actual code without worrying about the rest of the world blowing up.

💡 What’s Testing Without Mocks Like?

Let’s paint the scene.

You’ve got a service that pulls data from an external API or database. You write a test, and it:

Sends a real HTTP request ☁️
Connects to a real database 🧱
Waits... ⏳
Sometimes fails because the API is down 😮‍💨

Now imagine you’re running this test 50 times across different components. That’s not just fragile; it’s slow, noisy, and way too close to production for comfort.

🤝 Enter Mocks: Your Test Double

Mocks let you fake the parts of your system that don’t need to run for real in a test. Whether it’s an external API, a DB call, or even a complex function you mock it so your test can focus on the logic it’s actually meant to test.

Think of it like this:

You’re not trying to see if your third-party email API sends an actual email.
You’re just checking: did my app call the "SendEmail()" function with the right args?

🔧 So How Do Mocks Actually Work?

Behind the scenes, a mock replaces a real dependency with a controlled fake version that you can:

Pre-program to return specific values
Track: was it called? how many times?
Control: simulate errors, slow responses, etc.

Some mock tools even auto-generate mock code for your interfaces. It's vibes.

🧰 Mock Libraries You Should Know

📦 Node.js (JavaScript/TypeScript)

Jest

Built-in mocking support: jest.fn(), jest.mock()
Track function calls, set return values, simulate errors.
Docs: https://jestjs.io/docs/mock-functions

   const sendEmail = jest.fn();
   sendEmail.mockReturnValue('sent');
   expect(sendEmail).toHaveBeenCalled();

Sinon

Great for stubbing, spying, and mocking external dependencies.
Docs: https://sinonjs.org/releases/latest/mocks/

   const mock = sinon.mock(myService);
   mock.expects("getUser").once().returns({ name: "Mike" });

🐹 GoLang

Testify (Mock Package)

Lets you generate mocks for interfaces
Powerful assertions and control over mock behavior
Docs: https://pkg.go.dev/github.com/stretchr/testify/mock

   type MockEmailService struct {
       mock.Mock
   }

   func (m *MockEmailService) Send(to string, body string) error {
       args := m.Called(to, body)
       return args.Error(0)
   }

   emailMock := new(MockEmailService)
   emailMock.On("Send", "user@example.com", "Hi").Return(nil)

GoMock (Google’s Official Mocking Framework)

Slightly more setup-heavy but works beautifully with interfaces
Generates mocks via mockgen
Docs: https://github.com/golang/mock

🧪 Real World Example: Testing a Signup Flow

Let’s say you’ve got a signupUser function that does the following:

Saves the user to DB
Sends a welcome email
Logs a signup event

You don’t want your test to:

Actually save to the DB
Actually send an email
Actually log events to a service

You want to mock those services and just check:

“Hey, did they get called when I expected them to?”

🚀 Benefits of Using Mocks

✅ Faster tests (no real network calls)
✅ More reliable (no flaky external failures)
✅ Easier to isolate logic
✅ Lets you simulate edge cases & errors easily
✅ Clean architecture (forces you to use interfaces 👀)

💭 Final Thoughts

Mocking is one of those testing tools that once you get it, you never stop using it. It's not about skipping real tests—those still matter. It’s about giving your core logic a safe, fast sandbox to play in.

If you're serious about backend dev, mocking should absolutely be in your toolbox.

🧵 TL;DR:

Don’t test real dependencies every time.
Mock services you don’t control or don’t need to verify deeply.
Use jest, sinon, testify/mock, or gomock depending on your stack.
Write tests that are focused, fast, and less flaky.

The Layers of the Backend

Michael N. — Sat, 26 Jul 2025 21:51:32 +0000

One of the perks of working as a Software Developer at my current job is that I’ve gotten to see software development from a bunch of different angles. I’ve built stuff, shipped stuff, watched stuff break, and fixed it again. I’ve seen how infrastructure, while often behind the scenes, quietly shapes the cost and design of everything we build. But the part I’ve probably enjoyed the most? Learning how to structure large-scale backend systems. And that’s exactly what this piece is about.

So… What’s a “Layer”?

Let’s back up a bit.

Think of software like an onion. Not because it makes you cry (although… sometimes 👀), but because it has layers. Frontend, backend, database, infrastructure—all stacked together. But even within those broad categories, there are more layers hiding inside.

I used to think the backend was just APIs and a database. Request comes in, we fetch some stuff, maybe save some stuff, return a response—done. But over time, I realized there’s a better way to break things up. Just like the frontend has things like components or MVC (model-view-controller), the backend also benefits from a layered structure.

Here’s the version that’s stuck with me the most: API → Service → Repository.

Let’s peel each one open.

🛣️ API Layer

This is what talks directly to the outside world—your routes, your endpoints. It's where the frontend (or any external tool) makes a request. The API layer’s job is simple:

Handle routing
Authenticate the request
Validate input
Pass things along to the Service Layer

This layer should stay clean. No business logic here. Just making sure things are secure, valid, and sent to the right place.

🧠 Service Layer

This is where your app's brain lives.

All the business logic, the transformations, the “what should happen when X is true and Y is false” rules go here. You want to update a user’s profile picture? This is where the magic happens.

Need to call multiple repositories? Talk to an external service? Fire off an event? All that happens here.

And if you need to save or fetch anything, you call...

💾 Repository Layer

This layer handles all things database. No fancy logic. Just pure CRUD:

Save data
Fetch data
Update data
Delete data

Keeping it separate makes things easier to test and reuse. It’s like your backend’s personal librarian—knows where everything is, doesn’t mess with it.

📜 A Real-ish Example

Here’s what this looks like in a less structured setup. Imagine this all inside one giant API function:

func UpdateUsernameHandler(w http.ResponseWriter, r *http.Request) {
    // Auth check
    userID := r.Header.Get("X-User-ID")
    if userID == "" {
        http.Error(w, "Unauthorized", http.StatusUnauthorized)
        return
    }

    // Parse request
    var req struct {
        Username string `json:"username"`
    }
    err := json.NewDecoder(r.Body).Decode(&req)
    if err != nil || req.Username == "" {
        http.Error(w, "Invalid request", http.StatusBadRequest)
        return
    }

    // Update DB
    db.Exec("UPDATE users SET username = ? WHERE id = ?", req.Username, userID)

    // Return response
    w.WriteHeader(http.StatusOK)
    w.Write([]byte("Username updated"))
}

Now, this works, but imagine repeating that for every route. It becomes this spaghetti mess of auth checks, validation, business logic, and DB stuff all mashed together.

🧼 Cleaner Version (With Layers)

Let’s split it up.

API Layer:

func UpdateUsernameHandler(w http.ResponseWriter, r *http.Request) {
    userID := GetUserIDFromHeader(r)
    if userID == "" {
        respondUnauthorized(w)
        return
    }

    req, err := ParseAndValidateUsernameRequest(r)
    if err != nil {
        respondBadRequest(w, err)
        return
    }

    err = userService.UpdateUsername(userID, req.Username)
    if err != nil {
        respondServerError(w, err)
        return
    }

    respondSuccess(w, "Username updated")
}

Service Layer:

func (s *UserService) UpdateUsername(userID, newUsername string) error {
    if len(newUsername) < 3 {
        return errors.New("username too short")
    }

    // Optional: check if username already taken
    exists, _ := s.repo.DoesUsernameExist(newUsername)
    if exists {
        return errors.New("username already exists")
    }

    return s.repo.UpdateUsername(userID, newUsername)
}

Repository Layer:

func (r *UserRepo) UpdateUsername(userID, newUsername string) error {
    _, err := r.db.Exec("UPDATE users SET username = ? WHERE id = ?", newUsername, userID)
    return err
}

func (r *UserRepo) DoesUsernameExist(username string) (bool, error) {
    var count int
    err := r.db.QueryRow("SELECT COUNT(*) FROM users WHERE username = ?", username).Scan(&count)
    return count > 0, err
}

Why Bother?

This way of writing code is called Separation of Concerns, and once it clicks, it’s hard to go back.

Breaking things into layers helps you:

Reuse code (validation, auth, DB access)
Write smaller, focused functions
Test easily (mock a service, test a repo)
Onboard teammates without overwhelming them
Debug faster

Each layer has its own job. No one’s stepping on anyone else’s toes. You can evolve and scale your app without turning it into an unmaintainable nightmare.

Final Thoughts

This isn’t some strict rule. But once you start building bigger apps with more moving parts, splitting your code into layers will save your sanity. Just like onions add flavour to food (and tears to your eyes), backend layers add structure to your code (and prevent future crying during refactors 😅).

If you’ve ever struggled to keep things clean in your backend or found your functions growing out of control, give layering a shot.

Your future self will thank you.

Riding the AI Coding Wave Without Drowning Your Skills

Michael N. — Sat, 12 Jul 2025 22:57:50 +0000

AI has become a huge part of my development workflow from frontend to backend, all the way to DevOps. It’s fast, efficient, and lets me focus on the big-picture stuff. But recently, I caught myself just... vibing copy-pasting my way through the day. 😅

And while that can be tempting (especially on tight deadlines), I realised I needed to put some guardrails in place to keep learning, keep thinking, and not let my skills go soft.

So here are my 5 go-to rules to ride the AI coding wave like a pro without becoming over-reliant.

1. 🧠 Understand Before You Build

This is my remix of that classic line:

"Measure 20 times, cut once. Sharpen 1000 times... cut once." (okay, maybe too many cutting metaphors 😅)

The idea? Don’t dive in blind..
Before I write any code, whether it’s AI-assisted or not, I try to visualise the structure:

What’s the goal?
What are the components?
How will each part talk to the other?

Having a mental blueprint makes it easier to prompt AI intentionally, and helps keep my thinking sharp.

2. ✍️ Write What You Can

Writing code is how you really learn.
So I make a conscious effort to write as much of the code as I can myself especially logic-heavy parts, tricky loops, or things I want to get better at.

I might still ask AI for ideas, examples, or edge cases, but I don’t outsource the whole process.
That would be like going to the gym and making the weights lift themselves.

3. 🔍 Review, Review, Review

Never just copy-paste blindly.
Every time AI gives me code, I go into review mode:

Can this be cleaner?
Can I split this into smaller functions?
Do I understand what each line does?
Is there a better pattern to use?

Ironically, AI has made me better at code reviewing, which is a superpower in team environments.

4. 🧪 Test Everything

You guessed it: Test. Test. Test.

AI makes assumptions. Sometimes it gets edge cases wrong.
Sometimes you forget to mention a critical detail in your prompt. Either way, if you don’t test, you’re flying blind.

So yeah, I test AI code like I wrote it myself. Because if it breaks, that’s on me.

5. ☀️ Enjoy the Process

This one’s underrated.
Whether it’s debugging a stubborn bug or tweaking a layout for the 100th time, coding with AI should still feel creative and fun.

It’s easy to feel like AI is doing all the work, but when you’re intentional with your prompts, thinking deeply, and making decisions you’re still in the driver’s seat.

Enjoy it. Learn from it. Grow with it.

Final Thoughts

AI isn’t here to replace us; it’s here to amplify us.
But only if we stay sharp, curious, and engaged. These 5 rules help me code faster and better, without losing that developer edge.

So the next time you feel like you’re just vibing through your code, pause and check:

Are you building... or are you just pasting?

Let’s ride the AI wave with skill, not just speed. 🏄‍♂️💻

🧡 If you found this helpful, let’s connect.
Drop your favourite “AI + Dev” tips in the comments. I’m always down to learn more.

AI Is Dumb — And You Should Be Too (Here’s Why)

Michael N. — Sun, 29 Jun 2025 20:45:28 +0000

In a world where AI is becoming more prevalent, it’s more necessary than ever for us as junior developers to ensure we’re using AI responsibly. One key approach to achieving this is by understanding and applying core clean code principles — not just in our coding, but also in how we communicate with AI tools.

Why? Because writing great prompts is a lot like writing clean, maintainable code. Whether you're using ChatGPT, GitHub Copilot, or any other AI assistant, the way you ask matters. Prompts are the new code comments. They direct behaviour, define logic, and determine results.

Here are 5 essential clean code principles you can apply to your prompting style and AI usage — they’ll help you get better, more useful responses and cleaner, more maintainable code.

1. 🧠 KISS – Keep It Simple, Stupid

"Complex prompts confuse both AI and humans."

When prompting AI, avoid long-winded or overly complex instructions. Break big questions into smaller ones. This mirrors how you'd break a large function into smaller, more manageable pieces.

✅ Example Prompt:

“Write a function in Go to check if a number is prime. Use a loop.”

❌ Avoid:

“Write a fully optimised algorithm that determines prime status using multiple approaches and benchmark them with edge cases for performance analysis in Go.”

Simple wins. Start small, build up.

2. 🧱 SRP – Single Responsibility Principle

"A prompt should do one thing well."

Just like functions shouldn’t do multiple unrelated tasks, prompts should focus on one clear request at a time. This reduces ambiguity and improves the quality of the AI’s response.

✅ Example Prompt:

“Explain how to use Tailwind CSS to create a responsive navbar.”

If you also want to add dark mode, ask that as a separate prompt.

3. ✂️ YAGNI – You Aren’t Gonna Need It

"Don’t overprompt for things you don’t need yet."

Sometimes we’re tempted to ask for all possible use cases, error handling, and optimisation at once. But just like in coding, this leads to bloated, harder-to-read output.

✅ Prompt only what you need now. You can always refine it later.
This also keeps your output manageable, especially when you're learning.

4. 🧪 Write Testable Code (or Prompts!)

"Prompt in a way that allows you to validate and understand the output."

A good prompt should generate output you can test, tweak, and reuse. Ask for small code chunks or explanations with comments so you can follow along and learn, not just copy-paste.

✅ Better Prompt:

“Can you add inline comments to explain what this function is doing?”

This makes debugging and learning easier a win for responsible AI use.

5. 📦 Prefer Composition Over Inheritance

"Build complex prompts from simple, reusable parts."

AI thrives when you build prompts step-by-step. Instead of asking for an entire app or full module, ask for small building blocks (like reusable components or services), then compose them.

✅ Example Flow:

Ask for a login form UI
Then ask for a function to handle login
Then ask how to connect that logic to an API

This mirrors good development practices — modular, maintainable, understandable.

🌱 Final Thoughts

AI isn’t a magic wand. It’s a tool and like every tool, its value depends on how you use it. As junior developers, it’s not just about getting the job done with AI, it’s about learning how to do the job better.

By applying these clean code principles to your prompting, you’ll write better code, understand your tools more deeply, and develop habits that will future-proof your career, even in an AI-driven world.

Let’s build with intention, not just speed. AI is powerful but clean, thoughtful input is still king. 👑

How Network Communication Actually Works

Michael N. — Sun, 02 Feb 2025 18:35:00 +0000

Recently I went down a bit of a rabbit hole while working on some backend stuff. Coming from frontend development, I never really thought about how data moves around behind the scenes I just sent API requests and got responses, wham and done. But once I started digging into network communication, I realized there's a whole structure to it, and it’s kind of fascinating.

Turns out, when devices talk to each other, they don’t all communicate in the same way. There are three main modes: simplex, half-duplex, and full-duplex. And yeah, I had heard the terms before, but I never actually thought about what they meant. Now that I get it, I’m seeing them everywhere.

Simplex Communication: The One-Way Street

This one’s easy to understand. Imagine a one-way street: cars (or data) only go in one direction. That’s simplex. There’s no back-and-forth, just a continuous flow from sender to receiver.

🚦 Where this shows up in real life:

TV and radio broadcasts – The station sends out a signal, and we just receive it. No way to "talk back" to the station.
Keyboards – When you type, the data goes to the computer, but the keyboard itself isn’t receiving any data back.

Simplex is fine when you just need a steady stream of data going out, but obviously, it’s not great when two-way communication is needed.

Half-Duplex: The Walkie-Talkie System

Half-duplex is when two devices can talk to each other, but not at the same time. It’s like using a walkie-talkie only one person can speak at a time, and they have to wait for the other to finish before responding.

🎤 Where half-duplex is used:

Old Ethernet networks – Back in the day, Ethernet networks had to take turns sending and receiving data.
Two-way radios – Classic example. You say "Over," and then the other person replies.

It works, but it’s not the fastest or most efficient system. Still, it’s useful when bandwidth is limited, and devices need to share a communication channel.

Full-Duplex: The Smooth Conversation

Now, this is the good stuff. Full-duplex means data flows both ways at the same time just like a normal conversation. You don’t have to wait your turn; both sides can send and receive data simultaneously.

⚡ Where full-duplex shines:

Modern Ethernet – Most networks today use full-duplex, meaning devices can upload and download data at the same time.
TCP/IP (Internet communication) – The internet as we know it wouldn’t work well without full-duplex communication.
Phone calls – Imagine if you had to take turns speaking like a walkie-talkie. That would be weird.

This is obviously the best mode when speed and real-time interaction are important like video calls, gaming, or any kind of live communication.

I’ve never thought about this stuff before, but now I can’t unsee it. These communication modes are everywhere, affecting everything from how websites load to how streaming services work. And if you’re working on backend systems, understanding how data moves around helps make better decisions about performance, scalability, and protocol choices.

About the Author

Michael Nwaokocha is a software developer from Lagos, Nigeria. He enjoys building web apps with tools like JavaScript, React, Node.js, and Go. With a BSc Degree in Entrepreneurship, He likes solving problems and creating things that are easy to use. In his free time, he is usually learning or working on personal projects.

You can connect with him on LinkedIn, check out his projects on GitHub, or visit his blog.

Leveraging CSS Units for Responsive Web Design: A Detailed Study of Rem, Px, and Em

Michael N. — Sat, 03 Feb 2024 17:07:41 +0000

Introduction

When it comes to web development, CSS units play a crucial role in defining the size and spacing of elements on a page. Three commonly used units are rem, px, and em. Each has its own unique characteristics and use cases, and understanding their differences can empower developers to create more flexible and maintainable designs.

1. Rem (Root Em)

Rem, short for "root em," is a relative unit that is based on the root element's font size. Unlike em, which is relative to the parent element's font size, rem always refers to the font size of the root element (usually the HTML element). This makes rem a powerful and predictable unit for maintaining consistency across the entire page.

Use Cases for Rem:

Global Sizing: Rem is ideal for setting global font sizes, ensuring a consistent and scalable typography system across the entire website.
Responsive Layouts: When defining margins, padding, or any other spacing-related properties, rem allows for easy adjustments across different screen sizes, making your design responsive without the need for complex calculations.

2. Px (Pixels)

Px, or pixels, is an absolute unit that provides a fixed-size reference. Unlike relative units, px does not scale with the browser's default font size or the parent element's font size. Pixels are a precise unit of measurement, making them suitable for situations where exact control over the size of an element is essential.

Use Cases for Px:

Pixel-Perfect Designs: When you need precise control over the size of elements, such as images or fixed-width containers, px is the go-to unit for achieving pixel-perfect designs.
Print Stylesheets: In scenarios where print stylesheets are essential, using px ensures that the printed output retains the intended size and layout, as it is not affected by the user's browser settings.

3. Em (Relative to Parent)

Em is a relative unit that is based on the font size of the parent element. This makes em a flexible unit for defining sizes in a way that adapts to the surrounding context. Keep in mind that nesting em units can result in compounding effects, making it important to understand the hierarchy of your elements.

Use Cases for Em:

Scalable Typography: Em is commonly used for defining font sizes within specific elements. It allows for scalable typography that adapts to changes in the parent element's font size.
Flexible Layouts: When specifying margins, padding, or any other size-related properties, em is useful for creating layouts that respond to changes in the font size of the parent element.

Conclusion

In the world of web development, choosing the right CSS unit is essential for creating flexible, responsive, and maintainable designs. Rem, px, and em each have their own strengths and use cases, allowing developers to craft websites that not only look great but also adapt seamlessly to various screen sizes and user preferences. By mastering these units, you'll be better equipped to create a web experience that caters to the diverse needs of your audience.

Algorithms: Bubble Sort

Michael N. — Wed, 28 Sep 2022 17:05:52 +0000

Introduction

Bubble sort, also known as sinking sort, is a sorting algorithm that works by looping through an array or list of elements, comparing two elements at a time and swapping them if necessary. It does this until all elements are properly ordered. Let's look at an example of this in action.

Visualization

The algorithm starts at the first card [8] and compares it to the adjacent card [3], since [8] is greater than [3] so they swap positions, this is the core concept of bubble sort.

The algorithm moves through the list checking two elements at a time until each element is in its proper position.

Implementation

Let's break down this algorithm into steps before writing it out in code, so we understand how it works.

Loop through the array or list.
As we loop check if the current element is less than or greater than the next element.
If the current element is greater, then swap the position of the elements, otherwise move to the next element.
Repeat until no swapping occurs.

The above steps look like this in javascript code


function bubbleSort (array){
    for (var i = 0; i < array.length; i++) { // loop
      if (array[i] && array[i + 1] && array[i] > array[i + 1]) { //comprare
       let currentIndex = array[i];
       array[i] = array[i + 1];   // swap
       array[i + 1] = currentIndex; // swap
     }
  }
  return array
}

There's a problem with the above code, it will only loop through the array once, we need a way to keep the loop going until all elements in the array are sorted and then exit the loop, for this we use a boolean to represent the current state of the array and a while loop to keep the loop going until the state of the array is sorted. In javascript code, the algorithm looks like this.


function bubbleSort (array){
  let unsorted = true;
  while(unsorted){ 
    unsorted = false;
    for (var i = 0; i < array.length; i++) {
      if (array[i] && array[i + 1] && array[i] > array[i + 1]) {
       let currentIndex = array[i];
       array[i] = array[i + 1];
       array[i + 1] = currentIndex;
       unsorted = true;
     }
    }
  }
  return array
}

In the above function, we initialize a variable called unsorted and set the value to true, while unsorted remains true we shall keep looping through the array, when we enter the while loop we assume that we will find the array sorted so we set unsorted to false if the array is not sorted, which we will know when a swap occurs we set unsorted to true and loop through the array again. Only when a swap does not occur and unsorted remains false till the end of the for loop do we end the function because that means the array is sorted.

Time Complexity of Bubble Sort

Bubble sort has a worst and average complexity of O(n²), compared to other sorting algorithms, bubble sort ranks very low in efficiency and it is recommended that programmers do not use it when solving real-world problems.

Conclusion.

Bubble sort is meant to be an educational tool to introduce newbie programmers to the concept of algorithms as it is easy to understand and implement.