DEV Community: Nnamdi Felix Ibe

Day 29: A Pull Request Needs Two People, and Peering Needs Two Routes

Nnamdi Felix Ibe — Wed, 19 Aug 2026 19:51:41 +0000

Some things cannot be finished alone, by design. A change that only you have seen is not reviewed. A network connection that only works in one direction is not a connection. Day 29 was two versions of the same idea: both sides have to agree, and half of it is worse than none because half of it looks like it should work.

One Git task, one AWS task. Open a pull request, get it reviewed and merged, then peer a public VPC with a private one so instances on each side can talk. The tasks come from the KodeKloud Engineer platform.

Pull requests: the gate, not the merge

The first thing worth saying is that a pull request is not a Git feature. Git has no idea what one is. It is a workflow layer that hosting platforms bolt on top — Gitea here, GitHub and GitLab elsewhere — and underneath, a merged PR is git merge and nothing more.

Which raises the obvious question: if the merge is trivial, what is the PR for?

The gate. A named reviewer, a recorded approval, a discussion attached to the change, and a permanent record of who agreed to what. On this task, that meant opening the request against master from a feature branch, adding a second user as reviewer, then logging in as that user to read the diff, approve it, and merge with a merge commit.

# Everything before and after the PR is ordinary git
git log --oneline fox-grapes        # what you are proposing
git log --oneline master            # what it is going into

# ...PR happens in the web UI...

git checkout master
git pull origin master
git log --oneline --graph --all --decorate

Two things catch people out. Base and compare get reversed constantly — base is where the code is going, compare is where it comes from. Flip them, and you propose merging master into your feature branch, which usually shows nothing and reads as a broken UI rather than a mistake.

And the reviewer has to be a genuinely different user. Approving your own pull request is the one move that empties the mechanism of all meaning, which is why most platforms refuse it.

Worth knowing the third option too: "create a merge commit" preserves the branch shape, exactly the --no-ff behaviour from Day 25. Squash flattens the branch to one commit. Rebase replays them with no merge commit at all. Same code, three different stories in the history.

One small thing that trips everyone once: merging on the server does nothing to your local clone. git pull afterwards or your master sits silently behind.

VPC peering: one connection, two route tables

The AWS task was peering a public VPC with a private one so an instance in each could reach the other. And it opened with a problem that had nothing to do with peering at all.

SSH to the public instance simply hung. No refusal, no error — just silence. The cause was in the security group:

"IpPermissions": [{
  "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22,
  "IpRanges": [],
  "UserIdGroupPairs": [{ "GroupId": "sg-xxxxxxxx" }]
}]

That rule says "allow SSH from anything already inside this security group" — and the group it references is the one attached to the instance itself. Traffic from another instance in that group would match. My client host, sitting outside AWS entirely, never could.

That is the tell worth memorising: UserIdGroupPairs populated and IpRanges empty means the rule is SG-referenced, not CIDR-based. Nothing external gets in, and because security groups drop rather than reject, you get a hang instead of a message.

Then a second problem, which I liked. The task wanted my public key in the instance's authorized_keys. But writing that file needs SSH, and SSH needs that file.

EC2 Instance Connect breaks the loop. It pushes a public key to the instance out-of-band through the AWS API, valid for sixty seconds — long enough to get in and write the key permanently:

aws ec2-instance-connect send-ssh-public-key --region us-east-1 \
  --instance-id <instance-id> --instance-os-user ec2-user \
  --availability-zone us-east-1b \
  --ssh-public-key file:///root/.ssh/id_rsa.pub \
&& ssh -o StrictHostKeyChecking=no -i /root/.ssh/id_rsa ec2-user@<public-ip> \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '$(cat /root/.ssh/id_rsa.pub)' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

The && is not stylistic. Sixty seconds is not enough to run two commands you are typing by hand, and the second one failing on an expired key looks exactly like a permissions problem.

With access sorted, the peering itself is four checks, and this is the part that matters:

# 1. The connection must be ACTIVE, not pending-acceptance
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id <pcx-id>

# 2 and 3. A route on EACH side, pointing to the other's CIDR
aws ec2 create-route --route-table-id $DEF_RTB \
  --destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id <pcx-id>

aws ec2 create-route --route-table-id $PRIV_RTB \
  --destination-cidr-block 172.31.0.0/16 --vpc-peering-connection-id <pcx-id>

# 4. The target SG must allow the traffic type from the source CIDR
aws ec2 authorize-security-group-ingress --group-id <private-sg> \
  --protocol icmp --port -1 --cidr 172.31.0.0/16

Peering is bidirectional by nature but not by configuration. One connection object, two route tables, and you have to edit both. A route on only one side produces traffic that arrives and cannot reply, which presents as a total failure rather than a partial one.

Three details worth carrying forward. --port -1 with ICMP means all ICMP types — ping is ICMP, not TCP, so opening TCP ports does precisely nothing for it. If all four checks pass and it still fails, look at network ACLs, which, unlike security groups, are stateless and need explicit rules in both directions. And peering is not transitive: A peered to B and B peered to C does not let A reach C.

One honest note. I opened port 22 to 0.0.0.0/0 to get moving in a throwaway lab, which directly contradicts what I wrote on Day 22 about scoping SSH to /32. In a lab, that is a shortcut. Anywhere real, it is the thing you get audited for, and I would rather flag it than leave it in a code block.

Two small mistakes that cost me time, both embarrassing and both instructive. I pasted a placeholder straight into the shell — <sg-id> makes bash attempt an input redirect and throw No such file or directory. The angle brackets are notation, not syntax. And I ran ping "$PRIVATE_IP" on the remote host, where that variable had never been set. Local shell variables do not travel over SSH.

Half a handshake is not a handshake

An approval you gave yourself is not a review. A route on one side is not a path. Both tasks fail in the same quiet way: everything you configured is correct, and the thing still does not work, because the other half was never done.

So here is the Day 29 question. Where in your setup have you built one direction of something and assumed the other side agreed?

Day 29 down. Seventy-one to go.

Day 28: Cherry-Pick Takes One Commit, and the Tag Is the Address

Nnamdi Felix Ibe — Mon, 17 Aug 2026 16:51:42 +0000

Both of today's tasks came down to being precise about exactly what you are moving and exactly where it is going. In one, the answer is a single commit out of a branch full of them. In the other, it is an image whose destination is hidden somewhere you would not think to look.

One Git task, one AWS task. Cherry-pick one commit onto master, then create a private ECR repository and push a Docker image to it. The tasks come from the KodeKloud Engineer platform.

Cherry-pick: one commit, not the branch it came from

Merging takes a whole branch. Sometimes you want one commit out of it and nothing else — the fix that has to ship today, sitting on a feature branch that is nowhere near ready.

cd /usr/src/kodekloudrepos/<repo>

git branch -a
git log --oneline <feature-branch>
git show <commit-id>            # confirm it is the change you actually mean

git checkout master
git cherry-pick <commit-id>

git log --oneline
git status
git push origin master

The detail worth understanding is what actually happens. Cherry-pick does not move the commit. It copies the change, and the result gets a brand-new hash because a commit's identity includes its parent, and the parent is different now. The original stays exactly where it was on the source branch, untouched.

That has a consequence people meet the hard way. If you cherry-pick a fix onto master and then later merge the whole feature branch, Git is looking at two different commits containing the same diff. It frequently conflicts on the second one, and the conflict is confusing precisely because both sides look correct. Pick or merge. Try not to do both to the same change.

Two habits worth forming. Cherry-pick applies onto the branch you are standing on, exactly like merge, so git branch --show-current before you run it is two seconds well spent. And when you take several commits at once, order matters — git cherry-pick A B C applies them in the order given, and picking a commit whose dependency you skipped produces conflicts that look inexplicable until you notice the gap.

There is also a wider signal here. Cherry-picking is a precision instrument, and reaching for it constantly usually means the branching model is fighting you rather than helping.

ECR: docker push has nowhere to put an address

The AWS task was creating a private ECR repository and pushing an image into it. The commands are unremarkable right up until the one that actually matters.

export AWS_DEFAULT_REGION=us-east-1
aws sts get-caller-identity

aws ecr create-repository --repository-name xfusion-ecr --region us-east-1

REPO_URI=$(aws ecr describe-repositories \
  --repository-names xfusion-ecr \
  --query 'repositories[0].repositoryUri' --output text)
echo $REPO_URI
# <account-id>.dkr.ecr.us-east-1.amazonaws.com/xfusion-ecr

Then authenticate, build, tag, and push:

aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin $REPO_URI

cd /root/pyapp
docker build -t xfusion-ecr:latest .

docker tag xfusion-ecr:latest $REPO_URI:latest
docker push $REPO_URI:latest

Look closely at docker push. It takes no destination. There is no --registry flag, no target argument. The tag is the address. That docker tag line is not a cosmetic labelling step you can skip — it is the step that tells Docker which registry the image belongs to. Push a plain local name, and Docker assumes Docker Hub, tries there, and rejects you with an error that sounds like a permissions problem.

Once that clicks, the repository URI stops looking like noise and starts reading like what it is: <account-id>.dkr.ecr.<region>.amazonaws.com/<repo>. Your account, your region, your repository. An address, in address order.

Two security details in that login line. ECR credentials are temporary — get-login-password mints a token valid for about twelve hours, which is why it is piped straight into docker login rather than saved anywhere. And --password-stdin keeps that token out of your shell history and out of the process list, where --password on the command line would put it in both.

One last thing worth saying out loud, because it causes real problems later: latest is not a pointer that updates itself. It is a tag string like any other, and it moves only because you re-tag and re-push. Building a deployment on latest means you cannot reliably say what is running. Pin a digest or a real version tag for anything that matters.

Precision about what and where

Cherry-pick is the answer to "which change, exactly." The image tag is the answer to "which registry, exactly." Both tasks punished vagueness in the same way, by doing something plausible with the wrong target rather than refusing outright.

So here is the Day 28 question. When you move something — a change, an artifact, a config — is the destination stated somewhere you can read, or is it just implied by whatever the default happens to be?

Day 28 down. Seventy-two to go.

Day 27: Undo Isn't a Switch, and Neither Is Public

Nnamdi Felix Ibe — Sat, 15 Aug 2026 07:46:34 +0000

Two of the most common requests in this job are "undo that" and "make it public." Both sound like a single action. Neither one is. Day 27 was the day both of those turned out to be several things wearing one word.

One Git task, one AWS task. Revert a commit that has already been pushed, then configure a VPC so an EC2 instance inside it can actually reach the internet. The tasks come from the KodeKloud Engineer platform.

Revert: the undo that leaves a record

Git gives you two ways to undo a commit, and picking the wrong one is how teams end up in a bad afternoon.

cd /usr/src/kodekloudrepos/<repo>

git log --oneline
git show <commit-id>            # read it before you undo it

git revert <commit-id> --no-edit
git push origin master

git revert does not delete anything. It writes a new commit whose content is the exact inverse of the one you targeted. The original stays in the history, followed by a commit that undoes it. Two entries where you might have expected zero.

That feels wrong at first, and it is the entire point. Compare it to git reset, which moves the branch pointer backwards and rewrites what happened. Reset is genuinely useful and a local-only tool. The rule underneath both:

Never rewrite history you have already pushed.

Once a commit is on the remote, other people may have pulled it. Reset it away, force-push, and their next pull is a reconciliation problem they did not ask for. Revert is the version that is safe on shared history, because it only ever adds.

The history reads a little strangely afterwards — "did a thing", then "undid a thing" — and that honesty is the feature. Hiding the mistake is what the dangerous option does.

Two things that catch people. Reverting a merge commit fails unless you specify which parent is the mainline with -m 1. The error message reads like a bug the first time you hit it. And revert is itself revertible: revert the revert and you have reapplied the original change, with both moves on the record.

Public subnets: there is no public checkbox

The AWS task was making a VPC subnet genuinely reachable, and the first useful thing to internalise is that "public subnet" is not a setting. Nothing in the console is labelled public. A subnet is public if, and only if, its route table has a 0.0.0.0/0 route pointing to an Internet Gateway. That is the whole definition.

Which means it takes four separate pieces of wiring:

# 1. Create the gateway
IGW_ID=$(aws ec2 create-internet-gateway \
  --query 'InternetGateway.InternetGatewayId' --output text)

# 2. ATTACH it — an unattached IGW does nothing and says nothing
aws ec2 attach-internet-gateway --internet-gateway-id $IGW_ID --vpc-id $VPC_ID

# 3. Route table with a default route to the gateway
aws ec2 create-route --route-table-id $RTB_ID \
  --destination-cidr-block 0.0.0.0/0 --gateway-id $IGW_ID

# 4. Associate that route table with the subnet
aws ec2 associate-route-table --route-table-id $RTB_ID --subnet-id $SUBNET_ID

# and instances need an actual public address
aws ec2 modify-subnet-attribute --subnet-id $SUBNET_ID --map-public-ip-on-launch

Every VPC comes with a main route table that has only the local route and no path to the internet. A subnet you have not explicitly associated falls back to it, which is exactly why a freshly created subnet is silent.

Here is the part that makes this genuinely awkward to debug: miss any one of those steps and the symptom is identical. No error, no warning, just an instance that cannot reach anything. Creating an Internet Gateway and forgetting to attach it produces no complaint at all. Neither does a perfect route table that was never associated with your subnet.

So the only honest verification is from inside:

ssh ec2-user@<public-ip>
curl -I https://aws.amazon.com

Everything before that is configuration you believe is correct.

Worth knowing the mirror image: a private subnet that needs outbound-only access uses the same shape with a NAT Gateway as the route target instead of an IGW. Same four steps, different destination.

One word, several moving parts

"Undo it" is either an additive commit or a rewrite of shared history, and the difference decides whether your teammates have a good morning. "Make it public" is four separate resources that all have to agree, none of which is named public. In both cases, the word is a summary, and the summary is what hides the work.

So here is the Day 27 question. When someone asks you for a one-word change, do you know how many things that word is actually standing in for?

Day 27 down. Seventy-three to go.

Day 26: Origin Is Just a Nickname, and Localhost Tells the Truth

Nnamdi Felix Ibe — Wed, 12 Aug 2026 20:54:14 +0000

A lot of confusion in this field comes from taking a name at face value. origin sounds like it means something. A server that "isn't working" sounds like one problem. Day 26 was two tasks where the useful move was to stop trusting the label and go look at the thing itself.

One Git task, one AWS task. Manage the remotes on a repository, then configure an EC2 instance as a web server with Nginx. The tasks come from the KodeKloud Engineer platform.

Remotes: a nickname for a URL, and nothing else

A remote is not a connection. It is not a sync relationship. It is a name stored in a config file that maps to a URL. That is genuinely all it is.

git remote                      # names only
git remote -v                   # names plus URLs, fetch and push separately
git remote show origin          # full detail, including tracked branches

git remote add upstream <url> writes a few lines into .git/config. It does not contact the server, verify the URL, or download anything. You can add a remote pointing at a URL that does not exist, and Git will let you, right up until you try to use it.

Which means origin is not special. It is not a keyword. It is simply the name git clone happens to assign automatically, and you can rename it, retarget it, or work without one:

git remote add upstream http://git.example.com/<original-owner>/<repo>.git
git remote rename origin old-origin
git remote set-url origin git@github.com:user/repo.git
git remote remove upstream

set-url is the one to reach for when a repository moves or you are switching from HTTPS to SSH. Removing and re-adding gets you to the same place but throws away the tracking configuration on any branch that pointed at it, which you then get to set up again for no reason.

This is the other half of Day 23's fork. The convention on a fork is origin for your copy, the one you can push to, and upstream for the original, which you can usually only read. Nothing enforces those names. Everybody uses them anyway, and that shared habit is worth more than any rule.

One distinction that saves real confusion: git fetch downloads and stops, git pull is fetch plus an immediate merge into your current branch. Fetching first means you get to look at what arrived before it touches your work. And remote-tracking branches like origin/master are read-only local snapshots of where that branch stood the last time you fetched. They are not live. When origin/master looks stale, it usually is, because you have not fetched.

Nginx on EC2: ask localhost before you blame the network

Installing Nginx is three commands, and none of them is the interesting part:

sudo dnf install -y nginx              # Amazon Linux 2023, RHEL 9
sudo systemctl enable --now nginx
echo "<h1>Welcome to xFusion</h1>" | sudo tee /usr/share/nginx/html/index.html

enable --now is enable plus start together. Use only start, and you have a web server that quietly disappears on the next reboot, which is a miserable thing to discover weeks later.

Then comes the command that is worth more than the rest of the task combined:

curl http://localhost

Run this on the instance itself, before you touch anything on the AWS side. It splits the problem cleanly in two. If localhost answers and your public IP does not, Nginx is completely fine, and your problem is networking. If localhost does not answer, do not go near a security group, because the web server itself is broken and no firewall change will help.

Nine times out of ten localhost answers, and it is the same thing that bit me back on Day 22 with SSH:

aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID --protocol tcp --port 80 --cidr 0.0.0.0/0

A fresh security group allows no inbound traffic at all. Port 80 has to be opened deliberately, exactly like port 22 did. Same lesson, different port, and it will keep being the same lesson.

Two other things worth carrying forward. The document root differs by distribution — /usr/share/nginx/html on the RHEL family, /var/www/html on Debian and Ubuntu — which is how people end up carefully editing a file that nothing is serving. And never reload a config you have not validated:

sudo nginx -t                          # validate
sudo systemctl reload nginx            # apply without dropping connections

An error caught by nginx -t costs nothing. The same error applied to a live server takes the site down.

Worth noting where this lands: this is exactly the kind of instance that becomes a target behind the ALB from Day 24. The health check needs a 200 from whatever path it probes, so what you serve here decides whether the load balancer will send it traffic at all.

Check the thing, not the label

origin tells you nothing about where your code goes; git remote -v tells you. "The server is down" tells you nothing about where the failure is; curl localhost tells you. Both tasks came down to one cheap command that replaces an assumption with a fact, and both of those commands take about two seconds.

So here is the Day 26 question. Next time something is not working, what is the cheapest command that would tell you which half of the problem you are actually in?

Day 26 down. Seventy-four to go.

Day 25: Git Won't Guess, and an Unconfirmed Alarm Never Rings

Nnamdi Felix Ibe — Mon, 10 Aug 2026 20:29:57 +0000

Quarter of the way in, and Day 25 landed on a theme I did not expect: the last step of both tasks can only be completed by a person. Not a flag, not a retry, not a smarter command. A human has to decide something, and until they do, the system waits.

One Git task, one AWS task. Merge a feature branch back into master and deal with a conflict, then launch an EC2 instance and put a CloudWatch alarm on it. The tasks come from the KodeKloud Engineer platform.

Merging: two kinds, and Git picks for you

The first thing to get straight is direction. A merge runs from the branch you are merging into. You stand on master and pull the feature branch towards you, not the other way round.

git switch master
git pull                        # make sure master is current first
git merge feature-x

What happens next depends on something you did not choose. If master has not moved since the branch was created, Git performs a fast-forward: it simply slides the master pointer up to the tip of your branch. No merge commit exists. The history looks like the branch never happened.

If both branches have new commits, Git does a three-way merge and creates a merge commit with two parents, recording that two lines of work came back together.

That difference matters more than it sounds, because a fast-forward erases the shape of what you did. If you want the record kept:

git merge --no-ff feature-x
git log --graph --oneline --all --decorate

--no-ff forces a merge commit even when a fast-forward was available. It costs one commit and buys a permanent, readable record that a branch existed and when it landed. Plenty of teams require it for exactly that reason.

And then, sooner or later, this:

CONFLICT (content): Merge conflict in app.py
Automatic merge failed; fix conflicts and then commit the result.

A conflict is not an error, and it is not Git failing. It is Git refusing to guess. Two branches changed the same lines, and there is no correct answer available from the data alone, so it stops and hands the decision to you. That is the right behaviour, and it is worth reframing it that way, because the panic response is what causes damage.

git status                      # exactly which files are stuck

# Open each one, find the markers, decide what the file should say:
#   <<<<<<< HEAD           the version already on master
#   =======
#   >>>>>>> feature-x      the version from your branch

git add app.py                  # staging IS the resolution signal
git commit

Editing the file is not enough. git add is how you tell Git you have decided. Until the file is staged, the merge is still in progress no matter how clean the file looks.

And the safety valve nobody mentions until you are already sweating:

git merge --abort

That puts everything back exactly as it was. Knowing it exists is the difference between a conflict being a problem and a conflict being a nuisance.

The alarm: a threshold, a duration, and a link somebody has to click

The AWS side was launching an instance and alarming on its CPU. The alarm itself is one command, but two of its arguments carry all the meaning:

aws cloudwatch put-metric-alarm \
  --alarm-name nautilus-high-cpu \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions "Name=InstanceId,Value=$INSTANCE_ID" \
  --statistic Average \
  --period 300 --evaluation-periods 2 \
  --threshold 70 --comparison-operator GreaterThanThreshold \
  --alarm-actions $TOPIC_ARN

--period is the length of one measurement window in seconds. --evaluation-periods is how many consecutive windows have to breach before the alarm fires. Together, 300 and 2 mean CPU must stay above 70% for a full ten minutes. That is not pedantry, it is the difference between an alarm that tells you something and an alarm that screams every time a cron job runs and gets muted within a week.

--dimensions is what scopes the metric to one instance. Leave it off, and you get the aggregate across everything reporting that metric, which is rarely what anyone means.

The alarm notifies through an SNS topic, and an SNS email subscription does nothing at all until the recipient clicks a confirmation link:

aws sns subscribe --topic-arn $TOPIC_ARN \
  --protocol email --notification-endpoint ops@example.com

aws sns list-subscriptions-by-topic --topic-arn $TOPIC_ARN

If that comes back PendingConfirmation, your monitoring is decorative. The alarm will transition to ALARM exactly as designed, publish to the topic exactly as designed, and reach nobody. Every command succeeded. Nothing works.

Two more things worth knowing. A new alarm sits in INSUFFICIENT_DATA until enough data points arrive, which is expected rather than broken. And memory and disk usage are not default EC2 metrics at all, because the hypervisor cannot see inside the operating system. If you want those, you install the CloudWatch agent.

The step only a person can take

Both tasks end the same way. Git stages a conflict and waits for a human to say what the file should be. CloudWatch wires up a notification and waits for a human to confirm they want it. In both cases, everything upstream reports success, and the whole thing is inert until somebody does the last small thing.

So here is the Day 25 question. How much of your setup currently reports green while quietly waiting on a step nobody has taken?

Day 25 down. Seventy-five to go.

Egusi Soup. One Bowl, One Checkbox, Zero JavaScript

Nnamdi Felix Ibe — Sat, 08 Aug 2026 18:18:10 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Egusi soup with pounded yam. Jollof gets the headlines, but egusi is the quiet one that actually holds Nigerian homes together. Melon seeds, ugu, palm oil, and a dome of pounded yam you eat with your hands.

I already sent this challenge a love letter to jollof for the Perfect Landing prompt. This is the companion piece, and it targets a different audience: not a flat poster, but a photograph with real depth. The entire table sits in a single CSS perspective plane, so the bowl is genuinely a bowl. You look down into it.

Demo

A morsel of pounded yam is resting on top of the dome. Press "Dip the yam" and watch it lift off, cross the table, drop into the soup and come back stained. No JavaScript anywhere near it.

Journey

The rule I set myself: zero JavaScript. The one interactive moment runs on a checkbox and a sibling selector. The checkbox stays keyboard focusable, the label carries a visible focus ring, and if you've asked your system for reduced motion, the morsel skips the flight and just shows up stained.

The whole scene is sized in container query units, so it scales as one object from a phone to a desktop without a single media query for layout. Some of the tricks I'm proud of:

The table is one plane with transform-style: preserve-3d and a rotateX, so everything standing on it uses translateZ to mean "up off the table"
The bowl is six rings flaring up the Z axis. The top two are masked hollow, otherwise, they paint straight over the soup, and the whole thing reads as a solid disc. That bug is what taught me the technique
The soup sits below the rim on the Z axis, so you see the inner wall and the shadow it throws across the curds
The pounded yam is six contours stacked into a dome, each one a little brighter as it climbs toward the light
The egusi curds are eleven stacked radial gradients, the palm oil pools at the rim through an inset shadow, and the oil sheen is a blurred specular layer sitting over everything wet
The ugu leaves and the scattered raw egusi seeds are each one element cloned through a long box-shadow list
The raffia mat is a repeating radial gradient woven through a repeating conic gradient
The morsel is billboarded back toward the camera, because a sphere always projects as a circle, and its dip animates all three values of translate so it genuinely lifts, crosses and drops in

Two things I got wrong and had to fix. The bowl started as solid discs, which meant the soup was invisible until I masked the upper rings hollow. And I built the wood with plank seams running across the frame, which looked less like a table and more like a dark line drawn through my picture. It's one continuous surface now.

Hardest part? Light. Flat colours are easy; making CSS gradients behave like palm oil under a window took more attempts than I will admit. The glossy layer over the soup ended up doing half the realism on its own.

MIT licensed. The companion piece, Jollof, A Love Letter, is already up if you want the full table setting.

Day 24: A Branch Is Just a Pointer, and a Load Balancer Is Three Things

Nnamdi Felix Ibe — Sat, 08 Aug 2026 17:56:17 +0000

Almost everything useful in infrastructure is a layer of indirection. Something points at something else, and the pointing is what buys you the flexibility. Day 24 was two versions of that idea: a Git branch pointing at a commit, and a load balancer pointing at a pool of servers.

One Git task, one AWS task. Create a branch and publish it with tracking, then put an Application Load Balancer in front of two EC2 instances. The tasks come from the KodeKloud Engineer platform.

Branches: 41 bytes, not a copy

The mental model most people arrive with is that a branch is a copy of the codebase. It is not, and once that clicks, a lot of Git stops feeling expensive.

A branch is a file containing one commit hash. That is the whole thing. Creating a branch writes forty-odd bytes to disk, which is why it is instant on a repository of any size, and why branching freely is normal practice rather than something you ration.

git branch                      # local branches, * marks the current one
git branch -a                   # include remote-tracking branches
git branch -v                   # show the last commit on each

Creating one has a catch that gets everybody once:

# Creates the branch — and leaves you exactly where you were
git branch feature-x

# Creates AND switches
git checkout -b feature-x       # classic
git switch -c feature-x         # modern, Git 2.23 and later

git branch <name> creates without switching. You make the branch, carry on working, and every commit lands on the old branch. Nothing warns you. git branch --show-current before you commit is a cheap habit that catches it.

The switch and restore commands were split out of checkout in Git 2.23 for a good reason: checkout did two completely unrelated jobs, moving between branches and discarding local file changes. One typo could destroy work. The newer commands each do one thing, and there is no reason to keep reaching for the old one.

Then publish it:

git push -u origin feature-x

The -u sets the upstream tracking reference. Skip it and every later git push on that branch stops to tell you it does not know where to go.

One last thing worth knowing before you need it: git branch -d refuses to delete a branch with unmerged commits, while -D forces it. That refusal is a safety net. If -d complains, go and look at why before reaching for the capital letter.

The ALB: three parts, and all three have to exist

An Application Load Balancer is not one resource. It is three, and the most common first failure is building two of them and wondering why nothing responds.

The target group is the pool of backends plus the health check that decides who is in it. The load balancer is the thing that accepts traffic. The listener is the rule that connects them, saying which port and protocol to accept and what to do with what arrives.

TG_ARN=$(aws elbv2 create-target-group \
  --name nautilus-tg --protocol HTTP --port 80 \
  --vpc-id vpc-xxxxxxxx --target-type instance \
  --health-check-path /health \
  --query 'TargetGroups[0].TargetGroupArn' --output text)

aws elbv2 register-targets --target-group-arn $TG_ARN \
  --targets Id=i-1111111111111111 Id=i-2222222222222222

LB_ARN=$(aws elbv2 create-load-balancer \
  --name nautilus-alb --type application --scheme internet-facing \
  --subnets subnet-aaaaaaaa subnet-bbbbbbbb --security-groups sg-xxxxxxxx \
  --query 'LoadBalancers[0].LoadBalancerArn' --output text)

aws elbv2 create-listener --load-balancer-arn $LB_ARN \
  --protocol HTTP --port 80 \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

A load balancer with no listener accepts nothing. It exists, it has a DNS name, and it does absolutely nothing with your traffic.

The requirement that catches people on the first attempt is in the --subnets line: an ALB needs at least two subnets in two different availability zones. AWS enforces it, and it is not a suggestion. The load balancer is meant to survive an AZ failure, so it refuses to be built somewhere it could not.

Then:

aws elbv2 describe-target-health --target-group-arn $TG_ARN \
  --query 'TargetHealthDescriptions[*].{Target:Target.Id,State:TargetHealth.State,Reason:TargetHealth.Reason}'

If every target is unhealthy, the cause is almost always security groups, and specifically the second one nobody thinks about. The ALB's security group has to allow inbound from the internet. The instances' security group has to allow inbound from the ALB's security group on the target port. Get the first and miss the second and you have a working load balancer pointing at servers it cannot reach. The reason code tells you which: Target.Timeout means the traffic is being blocked, Target.ResponseCodeMismatch means it got through and the health check path returned the wrong status.

One thing to internalise: an ALB has a DNS name, never a static IP. Its addresses change underneath you. Point DNS at the name with a CNAME or a Route 53 alias and never write one of those IPs down.

Both are pointers

A branch points at a commit, so moving work around costs nothing. A target group points at instances, so replacing a server costs nothing either. In both cases, the indirection is the feature, and in both cases the thing being pointed at can change without anything upstream noticing.

So here is the Day 24 question. When something in your setup is expensive to change, is it actually expensive, or is it just missing the layer of indirection that would make it cheap?

Day 24 down. Seventy-six to go.

Day 23: A Fork Is Not a Clone, and Sync Is Not a Copy

Nnamdi Felix Ibe — Thu, 06 Aug 2026 05:36:58 +0000

Copying something is easy. Copying it in a way that still knows where it came from is the part worth learning. Day 23 was two copies of exactly that kind, one on a Git server and one between two S3 buckets, and both have a smarter option sitting next to the obvious one.

One Git task, one AWS task. Fork a repository and connect it back to the original, then migrate the contents of one S3 bucket into another. The tasks come from the KodeKloud Engineer platform.

Forking: the Git operation that isn't a Git command

Here is what surprised me. There is no git fork. Type it, and Git tells you it is not a command, because forking does not happen on your machine at all. It is a feature of the Git server, Gitea or GitHub or GitLab, which makes a full copy of a repository under a different owner and quietly records where that copy came from.

So the fork happens in a browser. What happens afterwards is where the Git work starts:

# Clone YOUR fork, not the original
git clone http://git.example.com/<your-user>/<repo>.git
cd <repo>

# origin points at your copy
git remote -v

At this point you have a copy that has already forgotten its parent, as far as your local repo is concerned. One remote, pointing at you. The fix is to add the original back by hand:

# Add the original repository as a second remote
git remote add upstream http://git.example.com/<original-owner>/<repo>.git

# Pull new work from the original into your fork
git fetch upstream
git merge upstream/master

git push origin master

origin and upstream are just names, not Git keywords, but the convention is worth following because everyone uses it: origin is your copy, the one you can push to, and upstream is the original, which you can usually only read from.

Three words get muddled constantly here, so it is worth being blunt about them. A fork is a copy on the server under a new owner. A clone is a copy on your local disk. A branch is a pointer inside one repository. Only the fork changes who owns the code, and that is exactly why it exists: you cannot push to a repository you do not own, so you fork it, push to your own copy, and ask the owner to pull your work in. That is the entire pull request model on every public project you have ever contributed to.

The trap is that a fork is a snapshot of one moment. It does not track the original. Leave it alone for a month, and it drifts behind, and you will find out when your pull request no longer applies cleanly.

S3 migration: sync knows what it already did

The AWS task was moving the contents of one bucket into another. The obvious command works:

aws s3 cp s3://source-bucket s3://destination-bucket --recursive

The better one is barely different to type and behaves nothing alike:

# Rehearse first — transfers nothing, prints everything it would do
aws s3 sync s3://source-bucket s3://destination-bucket --dryrun

aws s3 sync s3://source-bucket s3://destination-bucket

cp --recursive copies everything, every time, whether it changed or not. sync compares each object's size and last-modified time and transfers only the differences. On a small bucket, you will not notice. On a large one, that is the difference between re-running a failed transfer in seconds and starting the whole thing again from zero.

Two details make this better than it first looks. The transfer is server-side: S3 copies bucket to bucket inside AWS, so the objects never travel down to your terminal and back up again. Your laptop only issues API calls, which means a slow connection does not slow the migration. And because sync is incremental, it is safe to run repeatedly, which is what makes it usable as a scheduled job rather than a one-off.

Two flags deserve respect. --delete turns a copy into a mirror, removing anything in the destination that has no counterpart in the source. And aws s3 mv deletes from the source once each object lands, which without versioning enabled is not recoverable. Both are the right tool sometimes. Both should meet --dryrun first.

One thing to note is that objects arrive in the destination bucket's default storage class unless you pass --storage-class. If your source was sitting in something cheaper, a naive sync promotes the whole lot back to Standard, and you find out on the bill.

Copies that remember

Both tasks had a naive version that works and a better version that keeps context. Cloning a fork without adding upstream gives you code with no way back to its source. Copying a bucket with cp --recursive gives you data with no memory of what was already transferred. In both cases, the smarter option costs one extra line and saves you the moment where you realise you have lost the thread.

So here is the Day 23 question. Would you rather make a copy that stands alone and hope you never need to reconcile it, or spend one extra command keeping the link to where it came from?

Day 23 down. Seventy-seven to go

Day 22: Cloning a Repo, and Why Your New EC2 Refuses Your SSH

Nnamdi Felix Ibe — Mon, 03 Aug 2026 14:01:28 +0000

You can do every step of launching a server correctly and still be locked out of it. The instance is up, the key is right, and SSH still times out, because a firewall rule you never set is quietly turning you away. Day 22 closed the first stretch of this challenge on exactly that lesson.

One Linux task, one AWS task. Clone a Git repository into a target directory, then launch an EC2 instance with SSH key access and fix the security group when the connection is refused. The tasks come from the KodeKloud Engineer platform.

Git clone: two forms, one rule about the directory

# Clone into the current directory (must be empty)
cd /path/to/target
git clone <repo-url> .

# Or clone into a new named subdirectory (must not exist yet)
git clone <repo-url> directory-name

git log --oneline

Two forms, and the difference is the directory. git clone <url> . clones into the directory you are already in, which has to be empty. git clone <url> name creates a new subdirectory of that name, which must not already exist. Mix them up, and Git refuses rather than making a mess, which is the polite kind of failure. git log --oneline afterwards confirms the history actually came down.

EC2 with SSH: the launch is easy, the security group is the catch

The AWS side had more to it. Generate a key, import it to AWS, launch an instance with it, then connect. The launch used two patterns worth calling out:

# Latest Amazon Linux 2 AMI, straight from Parameter Store (never stale)
AMI_ID=$(aws ssm get-parameter \
  --name "/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2" \
  --query "Parameter.Value" --output text)

# Import your existing public key, then launch with it
aws ec2 import-key-pair --key-name id_rsa \
  --public-key-material fileb:///root/.ssh/id_rsa.pub

Two good habits here. Pulling the AMI ID from SSM Parameter Store means you always launch on the current Amazon Linux image instead of hardcoding one that goes stale, the exact problem I flagged back on Day 6. And import-key-pair uses fileb:// rather than file://, because a key is binary, so fileb reads raw bytes where file reads text.

Then the launch succeeds, the instance is running, and SSH hangs. The instance is fine. The problem is that the security group, which is the instance's firewall, has no rule allowing inbound port 22, so your connection never gets through. This is the single most common reason a fresh EC2 rejects you, and the fix is one rule:

# Your own public IP
MY_IP=$(curl -s https://checkip.amazonaws.com)

# Allow SSH from just your IP, not the whole internet
aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID --protocol tcp --port 22 --cidr "${MY_IP}/32"

The important detail is the /32. Opening port 22 to 0.0.0.0/0 would let the entire internet knock on your SSH door. Scoping it to your own IP with /32 means only your machine can reach it, least privilege applied to a firewall rule. The scripted connect also uses ssh -o StrictHostKeyChecking=no to skip the host-key prompt. That is fine inside automation where nothing can answer a prompt, but know what it gives up: that check is your protection against a man-in-the-middle, so it is a convenience with a real tradeoff, not a free one.

The last mile is access

Both tasks came down to the last mile, the small thing between "set up" and "actually reachable." The clone works or fails on one empty directory. The server is useless until one firewall rule lets you in. Everything upstream can be perfect, and the last rule is what decides whether you get to use any of it.

That is Day 22; the pattern across all of them has been the same one: the command is the easy part, and the thing it quietly depends on is where the real learning sits.

So here is the Day 22 question. Would you rather build everything and discover the access gap when you cannot get in, or check the last mile first, before you need it?

Day 22 down. Seventy-eight to go.

JOLLOF, A Love Letter. One Pot, Zero Photographs, All CSS

Nnamdi Felix Ibe — Sat, 01 Aug 2026 19:47:23 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

A love letter to Jollof rice, the dish I cook in Manchester when I need Lagos back for an hour.

It's a single landing page that tells the story of one pot. Where jollof came from, what goes in it layer by layer, the Nigeria vs Ghana argument that will outlive us all, and the five steps to cook it yourself. There isn't a single photograph on the page. Every dish, the top-down pot, the steam, the cross-section, is drawn in CSS.

Three things I cared about most:

Accessibility first. Semantic landmarks, a working skip link that moves focus, one open accordion pattern with proper aria wiring, a vote result announced through a live region, gold focus rings on everything, and a reduced-motion mode where nothing moves.
Interaction that earns its place. Open a layer in "Anatomy of the Pot", and the pot cross-section lights up that layer. Vote in the Jollof Wars and the tally stays on your device, because this war needs no central server.
A visual identity that isn't a food template. Flat editorial poster style, hard-edged shadows, two-tone display type split across the ground. If it looks like a restaurant theme from a template store, I failed.

Demo

Journey

I started with a rule: no photographs. Food sites lean on photography because it's the easy win, and I wanted to see how far layout, type, and flat CSS shapes could carry appetite on their own. The pot became one big orange circle, the rice became hard-stop radial gradients, and the steam became three animated wisps that go still if you prefer reduced motion.

The part I'm proud of is the anatomy section. The accordion drives the illustration, so the page explains the dish the way I'd explain it across a kitchen counter: layer by layer, base to smoke. The part that humbled me was the two-tone headline, which needs the text split to line up with the background split at every viewport width.

And the personal bit, since this challenge is about comfort. I'm Nigerian, I live in Greater Manchester, and jollof is the one dish that resets me when the week has been too much. Building this page was the cheapest therapy I've had all year.

Stack: hand-written HTML, CSS, and about 120 lines of vanilla JS. No frameworks, no images, no dependencies. Built with Claude as my pair, reviewed and argued over by me. MIT licensed.

So, one question before you go: Naija or Ghana? That is, if you had tasted both. If not, why not give it a go? The vote button is waiting.

Day 21: A Bare Git Repo Is the Hub, and an Elastic IP Is the Anchor

Nnamdi Felix Ibe — Sat, 01 Aug 2026 18:47:56 +0000

Every team's Git history lives on a repository nobody actually works in. It has no files you can open and edit, just the raw version data, and that emptiness is the entire point. Day 21 was building that central hub, and pairing it with the AWS equivalent of a fixed address, an Elastic IP that stays put.

One Linux task, one AWS task. Set up a bare Git repository on a storage server, then launch an EC2 instance and give it an Elastic IP. The tasks come from the KodeKloud Engineer platform.

The bare Git repo: a hub with no working tree

sudo yum install -y git
sudo mkdir -p /opt/media.git
sudo git init --bare /opt/media.git
ls /opt/media.git

The --bare flag is the whole idea. A normal Git repo has two parts, your working files and the hidden .git folder tracking their history. A bare repo has only the second part, the history, with no working tree at all. That is why bare repos are named with a .git suffix and why you never edit inside one directly.

Why would you want a repo you cannot work in? Because it is the shared hub. Developers push to it and pull from it, but nobody commits inside it, so there is never a checked-out branch to collide with an incoming push. This is exactly what GitHub and GitLab host on their side, a bare repo you sync against. Running git init --bare yourself is a good way to see there is no magic to a remote repo, it is just a repo with the working files left off. Keep the one distinction straight: git init makes a normal repo with a working directory for local development, git init --bare makes the central one everyone shares.

EC2 with an Elastic IP: launch, allocate, associate

On AWS, the task was to launch an instance and give it a static public IP, scripted end to end. The nice part is how it strings the steps together with bash variables:

# Launch, then capture the instance ID once it is running
aws ec2 run-instances --image-id ami-xxxx --instance-type t2.micro \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=xfusion-ec2}]'

INSTANCE_ID=$(aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=xfusion-ec2" \
  --query 'Reservations[*].Instances[*].InstanceId' --output text)

aws ec2 wait instance-running --instance-ids $INSTANCE_ID

# Allocate an Elastic IP, capture its allocation ID, then associate it
ALLOCATION_ID=$(aws ec2 allocate-address --domain vpc \
  --query 'AllocationId' --output text)

aws ec2 associate-address --instance-id $INSTANCE_ID --allocation-id $ALLOCATION_ID

Two habits worth stealing. Capturing each ID into a variable with $(...) turns the whole thing into a script instead of a copy-paste relay, so you never paste the wrong i-0abc halfway through. And aws ec2 wait instance-running blocks until the instance is genuinely up before you try to associate the address, so you are not racing the API. One reminder from Day 10, because it applies the moment you allocate: every public IPv4 address is billed now, attached or not, since AWS changed that in early 2024. An Elastic IP you allocate and forget still costs you, so release the ones you are not using.

Build the fixed point on purpose

Both tasks were about creating something stable for others to depend on. The bare repo is the fixed point a whole team's history hangs off. An Elastic IP is the fixed address that a service retains across restarts. Neither is glamorous, and both are the kind of quiet infrastructure everything else assumes is simply there.

So here is the Day 21 question. Would you rather build the stable centre deliberately and know exactly what depends on it, or let it emerge by accident and find out what breaks the day it moves?

Day 21 down. Seventy-nine to go.

Day 20: Wiring Nginx to PHP Over a Socket, and Giving EC2 a Role Without Keys

Nnamdi Felix Ibe — Thu, 30 Jul 2026 06:53:10 +0000

The best way to give one component access to another is usually the one that leaves no secret lying around. A local socket instead of an open network port. A temporary role instead of a hardcoded key. Day 20 was two versions of that idea, Nginx talking to PHP over a Unix socket, and EC2 getting AWS permissions through a role.

One Linux task, one AWS task. Wire Nginx to PHP-FPM through a Unix socket, then create an IAM role that EC2 instances can assume. The tasks come from the KodeKloud Engineer platform.

Nginx and PHP-FPM: connected by a socket, not a port

Nginx serves static files itself, but it cannot run PHP. It hands PHP requests off to PHP-FPM, a separate process that does the actual execution. The question is how the two talk, and here the answer is a Unix socket:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php-fpm/default.sock;   # PHP-FPM over a Unix socket
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

The location ~ \.php$ regex sends only .php requests to PHP-FPM; everything else Nginx serves statically. fastcgi_pass points at a socket file, not an IP and port. You could connect them over TCP with 127.0.0.1:9000 instead, but the Unix socket is the better local choice. It is a file on disk, so there is no network stack in the path and nothing listening on a port that could be reached from off the box. Less overhead, smaller surface.

The trap is ownership. Nginx and PHP-FPM have to agree on who owns that socket file, or Nginx gets permission-denied when it tries to connect. So PHP-FPM is configured to run as the nginx user and create the socket with matching ownership:

# In /etc/php-fpm.d/www.conf
# user = nginx
# group = nginx
# listen = /var/run/php-fpm/default.sock
# listen.owner = nginx
# listen.group = nginx

If PHP downloads as a file instead of running, or you get a 502, socket ownership is the first place to look.

IAM roles: permissions without a stored key

On AWS, the task was an IAM role for EC2. A role is how you grant an instance permission to call AWS services without putting an access key on the box. The instance assumes the role and receives temporary, rotating credentials instead.

# Trust policy: who is allowed to assume this role (the EC2 service)
aws iam create-role \
  --role-name EC2-Custom-Role \
  --assume-role-policy-document file://ec2-role-trust-policy.json

# Permissions policy: what the role can do once assumed
aws iam attach-role-policy \
  --role-name EC2-Custom-Role \
  --policy-arn <policy-arn>

A role has two policies doing two different jobs. The trust policy says who can assume it, here ec2.amazonaws.com. The permissions policy says what it can do once assumed. Two documents, two questions, do not mix them up.

Here is the step the task leaves out, and the one that trips people moving from the console to the CLI. A role by itself cannot be attached to an EC2 instance. EC2 uses an instance profile, a container that wraps the role, and in the console AWS creates that wrapper for you invisibly. From the CLI you do it by hand:

aws iam create-instance-profile --instance-profile-name EC2-Custom-Profile
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-Custom-Profile \
  --role-name EC2-Custom-Role

Then you attach the instance profile, not the role, to the instance. Miss this, and you have a perfectly good role that EC2 simply cannot use (per the AWS IAM docs).

Connect without leaking

Both tasks were about connecting two things the clean way. The Unix socket links Nginx and PHP without opening a port or leaving a network path exposed. The role links EC2 to AWS without a stored key that could leak. The lazy versions, a TCP port and a hardcoded credential, both work and both widen your attack surface for nothing in return.

So here is the Day 20 question. Would you rather connect your components the convenient way and carry the exposure, or the clean way that leaves nothing lying around to steal?

Day 20 down. Eighty to go.