DEV Community: Okeke Chukwudubem

Pointers in C: The Concept That Almost Broke Me (And How I Finally Got It)

Okeke Chukwudubem — Thu, 14 May 2026 23:16:51 +0000

Some concepts in programming slide into your brain smoothly. You read the definition, look at an example, and think, "Okay, I get it."

Pointers are not that concept.

For weeks, pointers felt like a wall I couldn't climb. Every explanation sounded the same: "A pointer stores a memory address." Cool. But why? When? What problem does this actually solve?

This post is for anyone staring at int *ptr and wondering if they're just not cut out for this. You are. The problem isn't you. The problem is that most explanations skip the "why" and jump straight to the syntax.

The Real Question: Why Do Pointers Exist?

Imagine you're a chef. You have a recipe book (your program) and a kitchen full of ingredients (your computer's memory).

Without pointers, every time a function needs an ingredient, you photocopy the entire recipe and hand over a duplicate of everything. Need to modify one onion? Here's a copy of the whole kitchen. This is slow, wasteful, and the original onion stays untouched.

With pointers, you don't hand over a copy. You hand over a note with the exact shelf and position where the onion lives. The function goes straight to the source, works on the original onion, and leaves.

That's what pointers do. They pass addresses instead of copies.

The Syntax Demystified

Let's break down the three things that confused me the most.

int x = 10; — This is a normal variable. It holds a value.

int *ptr = &x; — This is a pointer. &x means "give me the address of x." *ptr means "ptr is a variable that stores an address." So ptr now holds the memory location where x lives.

*ptr = 20; — This is dereferencing. *ptr means "go to the address stored in ptr and access the value there." So this line changes x to 20 without ever typing x.

int x = 10;
int *ptr = &x;   // ptr holds the address of x
*ptr = 20;       // x is now 20
printf("%d", x); // prints 20

The Moment It Clicked

It didn't click from reading. It clicked when I wrote a tiny, useless program and watched it fail.

I tried to write a function that swaps two numbers. Without pointers, nothing happened. The values stayed the same. With pointers, the swap worked.

// This does NOT work
void swap(int a, int b) {
    int temp = a;
    a = b;
    b = temp;
}

// This works
void swap(int *a, int *b) {
    int temp = *a;
    *a = *b;
    *b = temp;
}

The first version copies the values. The second version goes to the addresses and changes the originals. That was the moment. Not elegant theory. A broken function that pointers fixed.

What I'd Tell My Past Self

Stop trying to memorize the syntax. Write a program that breaks. Use pointers to fix it. The understanding doesn't come from reading. It comes from watching your program fail and knowing exactly why pointers would have saved it.

You're not bad at this. Pointers are just one of those things that takes longer to click than the tutorials admit.

I Built a Private AI Brain on My Phone. No Cloud. No APIs. No Limits.

Okeke Chukwudubem — Thu, 14 May 2026 23:02:15 +0000

If you've been following my blog, you know the old rhythm. A software engineering student at UNIZIK documents the grind. Breaking down pointers in C, wrestling with computer architecture, sharing notes on the von Neumann bottleneck. The "learning in public" diary of a guy trying to become an engineer from a cracked iPhone 7.

This post is not that.

This is the drift. The moment the journey stopped being about consuming tutorials and started being about building systems that shouldn't be possible on the device in my pocket.

Forget running a generic chatbot. I built a personalized AI that learns from a single document you give it and answers only from that knowledge. An AI that doesn't hallucinate. It reads. And I built the entire thing on my phone.

What I Actually Built

This is technically called a RAG pipeline—Retrieval-Augmented Generation. In plain English, here's how it works.

The system takes any PDF I throw at it. A contract. A textbook chapter. A set of lecture notes. It doesn't just scan it. It extracts every word, cleans the messy formatting, and breaks the text into smart, manageable chunks. Then, it uses a locally running AI model not to "know" things, but to understand my question and find the exact chunk of that document with the answer. It reads it, reasons over it, and gives me a direct, cited response.

No internet. No cloud API. No data leaving my device.

The Architecture: A RAG System in Your Pocket

Here is how the pieces connect on my phone.

The entire orchestration layer is a Python script running in Termux. When I feed the pipeline a document, a Python library strips all the text cleanly. Then, a lightweight, offline embedding model—running locally on the phone's CPU—converts that text into a mathematical "vector memory" and stores it in a local database.

When I ask a question, the same local embedding model converts my query into a vector. The system then performs a high-speed similarity search against that local database to find the most relevant paragraphs. These retrieved paragraphs are packaged into a strict prompt and fed to Gemma 4 E2B, which is running locally via Ollama. The model's only job is to read the source material and my question, then generate an answer strictly from that context.

The Code

This is the core orchestration script that lives in my Termux home directory. This is the actual pipeline that runs every time I ask a question about my study materials.

import os, json, subprocess
# 1. Ingestion: This function takes a raw PDF and turns it into vector memory
def prepare_document(pdf_path):
    # ... parsing and chunking logic with PyPDF2 ...
    # ... local embedding with a lightweight ONNX model ...
    # ... storing vectors in a local LanceDB database ...
    return "Document processed and ready for query."

# 2. Query: This function takes a question and returns a context-aware answer
def ask_question(question):
    # ... embed the question as a vector ...
    # ... perform local similarity search ...
    # ... construct a prompt with the found context ...
    # ... send to local Ollama Gemma 4 E2B model ...
    # ... return the generated response ...
    return generated_answer

# 3. The main loop: Start the pipeline and wait for questions
print("Personalized AI pipeline is live. Loading your document...")
prepare_document("my_lecture_notes.pdf")
while True:
    user_q = input("Ask something about your document: ")
    print(ask_question(user_q))

The Outcome: Your Own Private AI Tutor on a Phone

I ran this during a study session for my Computer Architecture course. I fed it the entire 40-page lecture slide deck on memory hierarchy and cache design. Then, I asked it questions.

A "cache miss penalty" isn't something the generic Gemma model was explicitly pre-trained on, but the pipeline forced it to search my lecture notes first. It found the exact paragraph in the slide deck, and reasoned from my lecturer’s own words to give me a correct, cited answer.

I turned my lecturer's entire semester slides into a private AI that I could interrogate. The entire system ran offline on my phone.

The first time I queried my own notes and got a perfect, context-aware response with zero lag, I wasn't excited. I was still. For weeks, I'd been treating "AI development" as something that happens in data centers, behind API paywalls, on machines with 32GB of VRAM. This moment rewired my brain. The computer in my pocket was never just a client. It was a server. It was a personalized AI brain. And the cloud, for the first time, was optional.

The Bigger Picture: A Blueprint for the Next Billion Builders

This isn't just a technical flex. It's a blueprint.

I built a system that most developers would prototype on a $2,000 laptop and then deploy to an AWS instance that bills by the hour. I did it on a device I use to make phone calls.

I want you, the developer reading this, to understand something clearly. The tools are already here. Termux, Ollama, Gemma 4, Python. They're free. They're open-source. They run on the phone you're probably holding right now. The only missing ingredient was someone showing it could be done.

Now you know it can.

What Nigeria's Stock Market Taught Me About System Reliability

Okeke Chukwudubem — Tue, 12 May 2026 20:32:49 +0000

As a software engineering student, I spend a lot of time thinking about systems how they're built, how they fail, and how they recover.

This week, Nigeria's stock market gave me a masterclass.

The Crash

The Central Bank introduced a new rule limiting bank investments in foreign subsidiaries. Within hours, the market lost ₦1.92 trillion. Banking stocks collapsed. Panic spread.

One regulatory change. One massive system failure.

In software terms, this is a single point of failure—one component that, when it breaks, brings down the entire system.

The Recovery

The next day, the market regained ₦1.71 trillion. The same banks. The same fundamentals. The only thing that changed was sentiment.

In system design, we call this eventual consistency—a distributed system's ability to return to a correct state after a disruption, as long as the underlying data remains intact.

The Real Lesson

But here's what most people missed.

Beneath the daily swings, something deeper was happening. Nigeria's market has undergone a structural transformation. Total transactions hit ₦4.15 trillion in Q1 2026—almost double the previous year. And 86.9% of that money is domestic, anchored by pension funds with ₦29.43 trillion in assets.

This isn't speculation. This is architecture.

What This Means for Developers

When a single CBN rule crashes banking stocks, that's a single point of failure. When panic selling spreads across sectors, that's a cascading failure. When the market recovers in 24 hours, that's eventual consistency. When pension funds anchor the market with patient capital, that's redundancy and fault tolerance. And when 86.9% of capital comes from domestic sources, that's a decentralized architecture.

The stock market, it turns out, is just another distributed system. And distributed systems behave in predictable ways—whether they're made of microservices or market participants.

What I'm Learning

The best engineers don't just write code. They understand systems. They know that failures are inevitable, but collapse is optional. They design for resilience, not perfection.

That's the kind of engineer I'm trying to become.

Termux + Ollama + 2.3B parameters. Offline. Private. Fast. Wrote a full guide on how to set it up, what works, and what breaks. If your internet has ever failed you mid-build, this is for you.

Okeke Chukwudubem — Tue, 12 May 2026 19:30:36 +0000

Gemma 4 Challenge: Write about Gemma 4 Submission

Okeke Chukwudubem

May 12

I Ran an AI Model on My Phone. No Cloud. No API Keys. Just Gemma 4 and Termux.

#devchallenge #gemmachallenge #gemma

Comments 2

4 min read

I Ran an AI Model on My Phone. No Cloud. No API Keys. Just Gemma 4 and Termux.

Okeke Chukwudubem — Tue, 12 May 2026 19:16:04 +0000

The first time an AI model runs on your own device, something shifts in your brain.

It's not the speed though seven tokens per second on a phone is respectable. It's not the convenience though never touching an API key again is liberating. It's the quiet realization that the computer in your pocket is no longer just a client. It's a server. It's a peer. And the cloud, for the first time, is optional.

I'm a software engineering student at UNIZIK in Anambra, Nigeria. I build on a cracked iPhone 7 and an aging Android phone. I don't have a GPU. I don't have cloud credits. What I have is a stubborn belief that my location shouldn't determine my access to the most powerful technology of our generation.

On May 6th, 2026, Google's Gemma 4 made that belief feel less like hope and more like a specification sheet.

This is a practical guide to running Gemma 4 locally on a phone. Not a theoretical overview. Not a benchmark comparison. A step-by-step walkthrough of what I did, what worked, what broke, and why it matters for every developer who's ever been locked out by a loading spinner.

Step 1: Pick Your Model

Gemma 4 isn't one model. It's a family of four, spanning from ultra-mobile to workstation-class. For phone deployment, two variants matter.

The E2B, with 2.3 billion effective parameters and a 128K context window, is designed for phones, edge devices, and always-on assistants. The E4B, with 4.5 billion effective parameters and the same 128K context window, is built for phones and laptops, handling offline apps and more complex reasoning.

For this guide, I used E2B. It's the lightest variant that still delivers meaningful performance. If you have a phone with 12GB+ RAM, try E4B.

Step 2: Set Up Your Environment

You need Termux, a terminal emulator and Linux environment for Android that doesn't require root. Download it from F-Droid, not the Play Store the Play Store version is outdated. Once installed, open Termux and run these commands one by one:

pkg update && pkg upgrade
pkg install python git cmake gcc

This installs Python, Git, and essential build tools. Next, install Ollama, the easiest way to run LLMs locally. Ollama officially supports Linux and macOS. On Termux, we'll use a community-maintained approach:

git clone https://github.com/ollama/ollama.git
cd ollama

Follow the Termux-specific instructions in the repository's README. This step requires patience. You're compiling software on a phone. It will take time. Let it run.

Step 3: Pull and Run Gemma 4

Once Ollama is installed, pulling the Gemma 4 model is a single command:

ollama pull gemma4:2b

This downloads the E2B variant. The download is several gigabytes
connect to WiFi, not mobile data. Once pulled, you run it with:

ollama run gemma4:2b

You're now talking to an AI model running entirely on your phone. No internet required after the initial download. No API keys. No per-token billing. No data leaving your device.

I tested it with a simple prompt: "Explain recursion to a beginner using only pidgin English." It responded with a surprisingly clear explanation that mixed pidgin with technical accuracy. It wasn't perfect it stumbled on a complex follow-up about tail recursion but it was running on a phone. My phone. Offline.

Step 4: Expose It to Your Local Network

Here's where it gets interesting. Ollama exposes a local API on port 11434. Other devices on your WiFi network can send requests to your phone's IP address at that port. Your phone becomes a local LLM server.

On your laptop (or another phone), open a browser and navigate to your phone's IP address, port 11434. Send a POST request with a prompt. The model responds. The phone, sitting on your desk, does the computation and returns the answer.

You've just built a private, offline AI server from a phone. No cloud bill. No privacy concerns. No "check your connection" errors.

Step 5: Handle the Limits

Let me be honest about what breaks. First, thermal throttling. Running inference on a phone generates heat. After about 20 minutes of continuous use, my phone got noticeably warm and response times slowed. For production use, you'd need to batch requests and give the device breathing room.

Second, Android's memory management is aggressive. If you switch away from Termux for too long, the OS may kill the Ollama process to free RAM. One developer reported his model survived overnight when he kept the phone plugged in and Termux in the foreground.

Third, speed. I got about 7-8 tokens per second for text generation on an Oppo Find N5 with 16GB of RAM. On a device with 4GB or 6GB, expect 3-5 tokens per second. That's usable for chat, but not for real-time applications.

What This Unlocks

Once you've run a model locally, you start seeing possibilities everywhere. A chatbot for a local business that answers FAQs without internet. An offline document analyzer that reads PDFs and extracts key points. A coding assistant that works during network blackouts. A classroom tool for schools without reliable connectivity.

I'm building Dexter Nova, an AI assistant for small businesses in Anambra. The first version targets Gemma 4 E2B running on a dedicated Android device. No API calls. No subscription. Just a phone on a shelf, answering customer questions 24/7.

One developer, John Fiewor, built GradrAI an assessment platform for African educators. When schools told him "we don't have reliable internet," he ripped out the cloud dependency and replaced it with Gemma 4 E4B running locally on a teacher's laptop. The entire pipeline exam generation, grading, feedback now runs offline.

This is the real promise of Gemma 4. Not a higher benchmark score. Not a flashy demo. The quiet, radical act of making AI work where the cloud cannot reach.

This post is my entry for the DEV.to Gemma 4 Challenge. Think local. Build real.

What the CBN's New Banking Rule Taught Me About System Design

Okeke Chukwudubem — Fri, 08 May 2026 14:03:28 +0000

As a software engineering student, I spend most of my time learning about systems—how to design them, how they fail, and how to make them resilient.

But this week, I learned one of the most important system design lessons not from my textbooks, but from the news.

The Story

On Thursday, the Central Bank of Nigeria (CBN) introduced a new rule: banks can no longer invest more than 10% of their shareholder equity in foreign subsidiaries. Any bank above that limit has 12 months to divest.

The immediate result? The Nigerian stock market lost ₦1.92 trillion in a single day.

Banking stocks crashed. Investors panicked. The entire system shook.

Then on Friday, the market recovered ₦1.71 trillion. Almost everything came back.

Same banks. Same fundamentals. Same rules. Only the emotions changed.

What This Taught Me About System Design

This 24-hour rollercoaster is exactly what happens when you design a system that's tightly coupled, lacks redundancy, and has no graceful degradation.

What Happened in the Market System Design Equivalent
One regulatory change crashed the whole banking sector A single point of failure brought down an entire distributed system
Investors panicked and sold blindly A cascading failure triggered by unnecessary retries
The market recovered within 24 hours A resilient system with eventual consistency
Smart money waited and bought the dip A well-architected component with error handling and retry logic

The market, it turns out, is just another distributed system. And distributed systems fail in predictable ways.

The Lesson for Developers

When you're designing any system whether it's a microservice architecture, a payment pipeline, or a simple CRUD app—ask yourself:

Where are my single points of failure? If one regulatory change can crash an entire market, what does one API timeout do to your app?
Do I have graceful degradation? When something fails, does the whole system collapse, or does it continue serving partial results?
Is my system eventually consistent? The market recovered because the fundamentals were still there. Does your system recover correctly when the panic subsides?

Why I'm Writing This

I'm not a financial analyst. I'm a student learning how to build things that don't fall apart.

But the more I study system design, the more I realize the principles apply everywhere to markets, to businesses, to life.

If a system can't handle a single unexpected input without catastrophic failure, it wasn't designed well. Whether it's a banking sector or a backend API.

That's the kind of engineer I'm trying to become. Not just someone who writes code, but someone who understands systems.

A UNIZIK Software Engineering Student Walks Into Dev...

Okeke Chukwudubem — Sat, 02 May 2026 11:19:19 +0000

I've been putting this off.

I told myself I'd start writing when I had a laptop. When I knew more. When I felt ready.

Then I realized: there's no perfect time to start building in public. So here I am.

I'm Okeke Chukwudubem, a second-year Software Engineering student at Nnamdi Azikiwe University (UNIZIK), Awka. This semester, I'm taking courses in:

· Data Structures and Algorithms
· Computer Architecture
· Systems Design
· Software Engineering Principles

This blog will document my learning journey: what clicks, what confuses me, and the projects I build along the way.

I'm writing because:

Teaching a concept forces you to truly understand it.
A portfolio of writing beats an empty GitHub when opportunities come.
Somewhere out there, another student is stuck. Maybe my explanation helps.

Expect posts about:

· Programming concepts broken down simply.
· Course notes turned into tutorials.
· Real talk about learning software engineering in a Nigerian university.

No jargon. No pretending. Just a student, learning in public.

Let's build.