DEV Community: CodenificienT

I Lost the Cluster: Six Weeks Dark, and the Rebuild That Followed

CodenificienT — Sun, 02 Aug 2026 01:58:24 +0000

Originally published on August 1, 2026 at afrotomation.com.

Between March and April 2026 I published four retrospectives about my infrastructure. Eight AI agents orchestrated on one Oracle box. Forty-seven apps moved off Vercel onto a self-hosted Coolify cluster. That cluster torn down nine days later and rebuilt on k3s with ArgoCD, SOPS, and CloudNativePG. Then a trenches post about the bugs that showed up three days in.

I was proud of all four. The last one even opened with a joke about how every infra retrospective ends with "and now everything works."

On June 15, 2026, at 04:54 UTC, the last write-ahead log segment shipped to my off-site backup bucket. Nothing shipped after it.

I did not find out until July 21.

By the time I looked, both Contabo nodes had been suspended for non-payment, then terminated. The disks were wiped. The IP address of my primary node had been reassigned to a different Contabo customer — who was, at that moment, serving their own Nextcloud on it, on a domain my DNS records still pointed at.

Almost every app I run was dark from June 15 to late July. This is the post-mortem, and the rebuild.

Part 1: What actually happened

The setup that failed

The k3s cluster was three nodes:

node	provider	role
`vps50`	Contabo	k3s server, CloudNativePG primary, GitLab CE, MinIO, MongoDB, Ghost, Uptime Kuma
`vps10`	Contabo	async Postgres replica, Loki
`ada`	Oracle Cloud (Always Free, ARM)	agent node

Two of those three nodes were on the same paid account with the same provider. That is the whole story in one sentence, and everything below is a footnote to it.

The timeline

~June 15 — Contabo billing lapses. Services suspended. WAL archiving to Backblaze B2 stops at 04:54 UTC. Last base backup was 04:04 the same morning.
~June 16 — mbp23, the MacBook that held my SOPS age key, my node SSH keys, and my kubeconfig, dies. It never powers on again. Multiple repair shops fail to revive it.
June 15 – July 21 — I am heads-down on client and agrobusiness work. Apps are down. I assume it's a transient thing I'll get to.
July 21 — I sit down to fix "the cluster" — on a new MacBook, which has none of it: no SOPS age key, no node SSH keys, no kubeconfig, not one real .env. Everything I'd need to touch the fleet died with the old machine. I pay the outstanding Contabo bill through payment links buried in the suspension emails, because the web panel won't let me log in. I probe 173.212.219.250, see port 443 answering, and conclude vps50 is alive but wedged.
July 22 — I discover the server answering on that IP is not mine. rDNS says vmd200597.contaboserver.net. It serves nextcloud.zumbahnhof40.de. Both my VPSes are terminated, both disks wiped, and my primary node's IP now belongs to a stranger. vps10 had already passed Contabo's 30-day recovery window and was unrecoverable by policy.

That July 21 reading — "the box is up, the cluster is just wedged" — is the part that still bothers me most. I was reading liveness off a machine I did not own and had no way to distinguish from my own. A port answering is not proof of identity.

What died, ranked

Gone, no copy anywhere:

GitLab CE — issues, merge requests, wikis, CI history, container registry. It ran as Omnibus with its own bundled Postgres inside a 60 GiB PVC, not on CloudNativePG. My backup job only ever touched the CNPG cluster. There was no gitlab-rake backup job. I had believed for months that GitLab was covered.
Loki — all log history, on the node that got terminated first.
MinIO object storage, MongoDB, Uptime Kuma history — no off-node backups at all, ever.
Ghost — the blog engine and its content. (The posts themselves survived in a separate export; more on that below.)
All Postgres writes between June 15 and June 30.

Survived:

Every repository. GitLab CE one-way mirrored to GitHub, so the code was safe even though the surrounding project management was not.
The CNPG app database, through June 15, in B2.
ada — the Oracle node. It's on the Always Free tier, so it was never billed, so it never lapsed. The one node I hadn't been paying for is the one that lived.

And one thing I had already written off. For weeks I carried sahelprosperity-wv in my head as the unrecoverable loss — GitLab-only, never mirrored, gone. It wasn't. The work was sitting on the main branch of the sahelprosperity GitHub repo the entire time, invisible to me because production deployed from master and master was the only branch I ever looked at.

That is its own small lesson, and not a flattering one: my inventory of what I owned was as stale as my backups. I spent part of an outage mourning something I already had. If you keep a list of what you'd lose, check it against git branch -a before you believe it.

The honest cause

It is tempting to write this as "self-hosting bit me" or "k3s was too complex." Neither is true, and both would be a cheap ending.

The actual failure chain:

Billing was an unmonitored production dependency. I watched pods. I did not watch invoices. An unpaid invoice took down more infrastructure than any outage in the previous two years.
My backups covered one database, not my platform. I had a mental model that said "Postgres is backed up, therefore my data is backed up." Six stateful services said otherwise. I never wrote down the list of things that hold state — if I had, the gaps would have been obvious in ten minutes.
I never tested a restore. My infra docs referenced two runbooks: restore-postgres-from-b2.md and replace-k3s-node.md. Neither was ever written. An untested backup is a hypothesis.
Key custody was a single point of failure that HA cannot fix. Three nodes, two providers, replicated Postgres — and one laptop holding the only copy of the SOPS age key and every SSH key. When that laptop died, my cluster was cryptographically unreachable regardless of how healthy it was. High availability of compute means nothing if access has a single copy.
Two of three nodes shared one failure domain. Same provider, same account, same invoice. I built what looked like a distributed system and it had the blast radius of one machine.

There is a smaller, more embarrassing finding too. When I later got into ada and looked at disk usage, a 146 GB ClickHouse volume turned out to be 99.9% ClickHouse's own internal logs — trace_log at 127 GB, text_log at 18 GB. The actual analytics data I cared about was 324 KB. A disk that full almost certainly caused kubelet disk-pressure evictions and contributed to the instability I'd been shrugging at for weeks.

Part 2: The rebuild

Ten days, roughly, from "I understand what happened" to "everything is green." Here's the order it went in, because the order mattered.

Step 0 — Stop pointing my domains at a stranger

Before restoring anything, I had to stop actively endangering myself and my users. My DNS still pointed dozens of hostnames at IPs that now belonged to other people.

I audited both zones and deleted:

85 A records aimed at the two reassigned Contabo IPs, across afrotomation.com and tioye.dev
96 stale TXT records — dead _acme-challenge entries and external-dns heritage junk

Zone sizes went from 95 → 15 records on afrotomation.com and 143 → 42 on tioye.dev.

Two of those records deserve calling out. cloud.afrotomation.com still pointed at the reassigned IP — meaning any device still running a Nextcloud sync client would have been offering credentials to a stranger's server. And Cloudflare's security scanner had flagged the second reassigned IP as an exposed RDP host: the new owner was running RDP on an address my DNS was still advertising as mine.

If you take one operational thing from this post: when a server dies, deleting its DNS records is the first task, not the last. A dead A record is not inert. It's a redirect to whoever gets that IP next.

Step 1 — Emergency landing zone on Netlify

I needed things visible before I needed them right. Netlify was the fastest path to that.

This immediately hit a licensing wall: neither Netlify's nor Vercel's free tier will deploy private organization-owned repos. So I transferred the deployable repos from the afrotomation org back to my personal GitHub account, and pushed the priority apps out:

tioye.dev — the portfolio. The domain had actually lapsed into expired-grace during the outage; I renewed it and transferred the registrar to Cloudflare the same day.
auth.afrotomation.com — the SSO server, which everything else depends on. This had to come up first.
afrotomation.com, plus ClickRise, SahelFoods, Bugginator, Sahel Prosperity.

Reviving SSO took three stacked fixes, each hiding the next:

My password hash predated the June 15 backup, so the credentials in the restored database were older than the ones in my password manager. I generated a fresh Better Auth scrypt hash locally and updated the row directly.
Sign-in then returned 429 for everyone. The rate limiter was failing closed because its Upstash Redis credentials had died with the cluster. I changed it: production without Redis now degrades to in-memory limiting, with RATE_LIMIT_FAIL_CLOSED=true available to restore strict behavior deliberately.
get-session then threw "Failed to decrypt private key." The JWKS row in the database was encrypted with the old BETTER_AUTH_SECRET — which was gone with the cluster. Deleting the row let Better Auth regenerate the keypair.

Every one of those three is a "your secrets were cluster-side" problem in a different costume.

Netlify's own limits then bit: I burned 363 of 300 monthly credits, and the failure mode was strange — external uptime checkers reported 200s while the sites were genuinely unreachable from some edge locations. Don't trust third-party "it's up globally" checks for an over-limit account. I upgraded, and reachability was restored immediately.

Step 2 — Get back into the Oracle box

ada had survived. I could not log into it.

The authorized SSH key was on the dead laptop. I tried the documented escape hatches:

OCI Run Command — unavailable. The Ubuntu Minimal image ships 11 plugins, and Compute Instance Run Command isn't one of them.
OCI Bastion — created the bastion and a managed SSH session, watched it hang in Creating for eight minutes, and gave up. Not a firewall problem, since public SSH answered fine. The plugin reported Enabled and Running and simply did not work.

What worked was a boot-volume swap: detach ada's boot volume, attach it as a data volume to a second throwaway instance, mount it, write my new public key into authorized_keys, detach, reattach, boot. Crude, reliable, no vendor tooling involved.

One thing to know if you ever do this: ada has two users, opc at UID 1000 and ubuntu at UID 1001. Assuming 1000 is the login account will waste you an hour.

Step 3 — Demolish the zombie

ada was still running a k3s agent pointed at a control plane that no longer existed. ingress-nginx was 404ing on 80/443 with an afrotomation.com certificate that had expired on July 23. The API server was down, etcd quorum permanently lost. Nothing there was recoverable.

Uninstalling reclaimed 164 GB — the box went from 190/193 GB used to 35 GB.

A gotcha worth writing down: if both k3s-uninstall.sh and k3s-agent-uninstall.sh exist on a node, the server uninstaller bails with "Additional k3s services installed, skipping" and removes only the systemd unit. The agent uninstaller is the one that actually deletes /var/lib/rancher.

Step 4 — Coolify, and the four things that blocked it

Coolify 4.1.2 went on the box. The dashboard lives on port 8000 and I deliberately never opened that port publicly — it's reachable over Tailscale only.

Then four fleet-wide blockers, in the order they surfaced:

1. Ingress: the OCI security list only allows port 22. Not the instance firewall — the VCN itself. I proved it with tcpdump: 0 packets captured while curling from outside. The confusing part is that Oracle's virtual network completes the TCP handshake before dropping you, so nc cheerfully reports success on a port that will never deliver a byte. Use curl or tcpdump, never nc, to test this.

The fix wasn't allowlisting Cloudflare's CIDRs. ada was already running a healthy cloudflared tunnel left over from an earlier era. I repointed its ingress at the new Traefik and the origin stayed sealed — curl http://<public-ip>/ returns nothing at all, while everything serves fine through Cloudflare.

2. The tunnel has to speak HTTPS to Traefik. Routing *.afrotomation.com to http://127.0.0.1:80 produces an infinite redirect loop, because Coolify's Traefik force-redirects HTTP→HTTPS and the response bounces back out through Cloudflare. The working shape:

  - hostname: "*.afrotomation.com"
    service: https://127.0.0.1:443
    originRequest:
      noTLSVerify: true

noTLSVerify is fine here — the hop is loopback and the tunnel is already encrypted.

Also: cloudflared tunnel route dns only works for the zone the tunnel's cert covers. Point it at a tioye.dev hostname and it will silently create tioye.dev.afrotomation.com instead of erroring. Second-zone hostnames need the CNAME created by hand.

3. bun does not install on ARM + Alpine — and it broke 47 of my 55 Dockerfiles. Every one of them had RUN npm install -g bun@X, which fails on aarch64 musl with Failed to find package "@oven/bun-linux-aarch64". Bun's npm distribution has no musl+ARM build. The one-line fix, which also respects my no-Docker-Hub policy since the GCR mirror carries it:

COPY --from=mirror.gcr.io/oven/bun:1.2.17-alpine /usr/local/bin/bun /usr/local/bin/bun

4. Deploy keys were disabled at the GitHub org level, so Coolify could not clone a single private repo. One org setting, forty broken deploys.

(There was a fifth, chronic one: stale bun.lock files from Renovate PRs that were never rebuilt. bun install --frozen-lockfile dies with "lockfile had changes, but lockfile is frozen." bun install --lockfile-only, commit, move on. This same problem had already bitten me on Netlify.)

With those cleared, deploys became routine: dedicated read-only deploy key per repo, POST /applications/private-deploy-key, DNS via the tunnel, deploy. About three minutes per app. As of August 1, all 41 resources in the Coolify project report running.

Step 5 — The data

One Coolify-managed PostgreSQL instance, one database per app.

The image matters: postgis/postgis is amd64-only — the exact wall that had kept Postgres off the ARM node in the old cluster. The multi-arch community build imresamu/postgis:17-3.5 works, reporting PostgreSQL 17.6 on aarch64.

Then I restored the B2 backup into a scratch instance and merged it into the live databases. Additive only — INSERT ... WHERE NOT EXISTS (pk), never update, never delete, converges to zero rows on a re-run. Run it repeatedly to a fixpoint, because child rows need their parents from an earlier pass.

Roughly 14,000 rows came back:

database	rows recovered
clickrise	9,260
bookshelf	4,462
sahelfoods	190
codeniserver	24
everything else	~22

Four staging traps each produced a "successful" merge that silently skipped most tables. The only reason I caught them was asserting that the staged table count equalled the source table count:

\restrict in plain-SQL dumps. Modern pg_dump wraps plain output in \restrict/\unrestrict; psql then rejects the \. COPY terminators and most tables fail to load. Use --format=custom and pg_restore.
Missing uuid-ossp. Columns default to uuid_generate_v4(); without the extension, every such table fails to create.
ALTER SCHEMA public RENAME TO bk moves the extensions with it, so those defaults become bk.uuid_generate_v4() — which won't exist in the live database. Strip defaults and FK/CHECK constraints from the staging schema after renaming (keep the primary keys; the merge needs them).
Per-account ID drift. The backup and the live database issued different IDs for the same email. You have to build an old→new map by joining on lower(email) and rewrite every foreign key onto users. Hard-coding one admin ID recovers almost nothing — that mistake is what initially hid two OAuth clients owned by a different test identity.

Two apps turned out not to have lost data at all — they'd drifted behind their own migrations. bookshelf was nine Prisma migrations behind, blocked by a failed migration inherited from its previous host that ended in a GRANT to a role that didn't exist on the new box. sahelfoods had no Drizzle migrations table whatsoever and only 61 of its 86 tables. Both recovered once the schema caught up.

Every application database is now on the box. Zero Neon references remain in any deployed app.

Step 6 — Split the fleet on purpose

The old architecture put everything behind one control plane. The new one deliberately does not:

tier	platform	what lives there
Dynamic apps	Coolify on Oracle `ada` (4 OCPU / 24 GB ARM)	41 resources — Next.js apps, Postgres, supporting services
Static sites	Cloudflare Pages	6 CRA/static builds, direct-upload via `wrangler`
Overflow / legacy	Netlify	11 remaining non-cornerstone sites
Blog	dev.to	43 posts

Cloudflare Pages gotchas, since they cost me time: it rejects any file over 25 MiB (a CRA source map killed one deploy — GENERATE_SOURCEMAP=false), it sets CI=true which promotes CRA ESLint warnings to build errors, and its default npm ci fails across this entire fleet because every repo uses bun.lock and none has a package-lock.json.

The sizing constraint on the Coolify box is CPU, not memory: 24 GB fits about 40 containers, but 4 OCPUs realistically supports 25–30 apps with concurrent builds set to 1.

Step 7 — The blog moved to dev.to

Ghost died with the cluster. I did not want to run a blog engine again.

I considered Hashnode — I'd used it before — but its API went Pro-only in May 2026, and I'm not paying a subscription for write access to my own words. dev.to it is. All 43 posts are live there, and tioye.dev/blog renders from the dev.to API through a lib/devto.ts module that replaced the dead Ghost client with the same interface.

Two dev.to API lessons, both of which cost me real time:

RSS-imported articles embed front matter inside body_markdown, and a published: false in that embedded block overrides the API's published field. You have to rewrite the body's front matter to actually publish them.
The API rejects backdated published_at — "only future or current." So 23 older posts are all stamped with their import date, and the site parses each post's true date out of its opening "Originally published on…" line and sorts by that instead.

And one gotcha that had nothing to do with dev.to: after the swap, browsers reported "Failed to fetch" while server-side renders worked perfectly. My next.config.js CSP connect-src still allowed only the dead Ghost origin. When you change a client-fetched data source, update your CSP and your image remotePatterns in the same commit.

Step 8 — The things that quietly depended on the cluster

Weeks later I was still finding these.

My portfolio's project screenshots came from a k3s CronJob. With that gone, the grid fell back to a live third-party capture API on every card render, blew through its free daily quota instantly, and rendered "coming soon" placeholders across the whole page. The replacement is a headless Chromium container on the box, cron'd for Sunday mornings, uploading to Cloudinary — 41 real covers, zero placeholders.

(Docker note, since this one wasted an afternoon: headless Chromium needs --shm-size=1g alongside --disable-dev-shm-usage. With Docker's default 64 MB /dev/shm, the GPU process crashes mid-capture and writes no file at all — no error, no image.)

While auditing costs I also found the actual money leak, and it wasn't hosting. 99 repositories were running Renovate on bare config:recommended — no schedule, no grouping. Every dependency PR fired a CI build. That, plus 37 dead workflow files still pointing at a runner set that no longer existed, was the burn. Throttled, deleted, and Dependabot removed from the 30 repos where it overlapped with Renovate.

What I'd tell April-me

Write the list of stateful things. Not "is Postgres backed up" — an actual enumerated list of every service that holds state, with the backup mechanism next to each one, and a blank next to the ones without. Mine would have had six blanks and I'd have seen it in ten minutes.

A backup you haven't restored is a hypothesis. Both of my restore runbooks were referenced in documentation and never written. Restore into a scratch environment on a schedule, or you don't know what you have.

Get your keys off your laptop. Not "back them up eventually" — today. HA compute plus single-copy credentials is not a resilient system, it's a fragile system with expensive decoration. My cluster was fine. I just couldn't get in.

Billing is production. Put invoices and card expiries in the same alerting channel as your uptime checks. A lapsed payment did more damage to me than any technical failure in two years.

Spread the blast radius across providers, not just machines. Three nodes across two providers still meant two-thirds of my cluster on one invoice. The node that survived is the one on a tier that cannot lapse for non-payment.

Delete DNS for dead hosts immediately. A dangling A record isn't a broken link. It's a live pointer at whoever the cloud provider hands that IP to next — and in my case that was someone running an exposed RDP service on an address my domain was still vouching for.

Don't trust liveness you didn't design. I spent a day working from the belief that my server was up, because something answered on its IP. Check identity — a TLS certificate, a health endpoint you wrote, an rDNS lookup — not just a port.

Was self-hosting the mistake?

No, and I want to be precise about why, because "just use a PaaS" is the wrong lesson to draw from this.

Nothing here was caused by Kubernetes being hard, or by running my own metal. The cluster didn't crash. It was deleted, by a billing event, and I couldn't recover it because I'd centralized the recovery path into one laptop and one incomplete backup job. Those are operational failures I'd have committed on any platform. Vercel taught me the same lesson from the opposite direction last year — that's why I self-host.

What did change is the shape. The old fleet was one control plane, one key, one backup target: a distributed system with the blast radius of a single machine. The new one is three independent tiers on three independent providers, with credentials that live somewhere other than my desk. If the Oracle box vanishes tomorrow, the static sites stay up and the blog stays up, and the recovery path is a rebuild script and a password manager rather than a boot-volume swap and a prayer.

Six weeks dark is a real cost. But I'd been running on an untested backup for months and simply hadn't found out yet. I'd rather have found out this way than the next way.

Still open

Being honest to the end, this isn't finished:

SSO's auth database is off Netlify but still on a managed provider — it hasn't been migrated to the box yet.
Eleven legacy sites are still on Netlify pending review.
Distributed rate limiting still needs a Redis to come back.
Every credential that ever sat on those Contabo disks — OAuth client secrets included — still needs rotating. Someone else owned those disks. It is the longest item on the list and the easiest to keep postponing.

This is part of the **Afrotomation Startup* series — building an automation agency in public, including the parts that go badly. Previous entries: 47 Apps, One Week · From Click-Ops to GitOps · Three Days In.*

The Aspiring AI Engineer: Educative Learning Path

CodenificienT — Tue, 28 Jul 2026 03:51:04 +0000

Published on Aug 28th, 2025

I've just finished Module 1: Learn Python from the Machine Learning Engineer Career Path on Educative.com, and I'm excited to share what I've learned! This foundational module has equipped me with the essential Python programming skills needed to tackle machine learning algorithms and data science projects.

🚀 What I Accomplished

Over the course of Module 1, I completed 40+ hands-on Python exercises that covered everything from basic syntax to building interactive applications. Each exercise was designed to reinforce programming concepts through practical, real-world scenarios.

📚 Core Concepts Mastered

1. Python Fundamentals & Syntax

Variables & Data Types: Learned to work with strings, integers, floats, and boolean values
Input/Output Operations: Mastered print() statements and input() functions for user interaction
Basic Operations: Arithmetic operations, string concatenation, and type conversion

Example from my work:

# Hello.py - My first Python program
print("Welcome to the Machine Learning course by Educative!!")

2. Control Flow & Decision Making

Conditional Statements: Implemented if, elif, and else statements for program logic
Comparison Operators: Used ==, !=, <, >, <=, >= for decision making
Logical Operators: Combined conditions with and, or, and not

Real-world application:

# Conditionals Movies.py - Age-appropriate movie recommendations
age = int(input("Enter your age: "))
if age >= 18:
    print("You can watch R-rated movies")
elif age >= 13:
    print("You can watch PG-13 movies")
else:
    print("You can watch PG movies")

3. Loops & Iteration

For Loops: Iterated through lists, ranges, and sequences
While Loops: Created programs that run until specific conditions are met
Loop Control: Used break and continue statements effectively

Practical example:

# While Loops.py - Interactive user input handling
while True:
    name = input("Enter your name (or 'quit' to exit): ")
    if name.lower() == 'quit':
        break
    print(f"Hello, {name}!")

4. Data Structures

Lists: Created, modified, and manipulated ordered collections
Dictionaries: Built key-value pairs for storing related information
Data Manipulation: Added, removed, and updated elements in collections

Hands-on practice:

# Lists.py - Working with collections
fruits = ["apple", "banana", "orange"]
fruits.append("grape")
print(f"Available fruits: {fruits}")

5. Functions & Code Organization

Function Definition: Created reusable code blocks with def statements
Parameters & Return Values: Built functions that accept input and produce output
Code Reusability: Organized code into logical, maintainable functions

Advanced function example:

# function adv layers.py - Interactive storytelling
def jungle_adventure():
    path = input("You find two paths: one goes to a river, the other to a mountain. Where do you go? ")

    if path == "river":
        print("You swim with dolphins!")
    elif path == "mountain":
        print("You find an ancient temple!")
    else:
        print("You wander into the savannah and get lost.")

jungle_adventure()

6. File Operations

Reading Files: Opened and processed data from text files
Writing Files: Created and updated files to store information
File Management: Handled file paths, error handling, and data persistence

Practical file handling:

# file diary.py - Personal journal system
with open("diary.txt", "a") as file:
    entry = input("Write your diary entry: ")
    file.write(f"{entry}\n")

7. Graphics & Visualization

Turtle Graphics: Created visual patterns and shapes using Python's turtle module
Color Manipulation: Applied different colors and styles to graphics
Geometric Drawing: Built hexagons, spirals, and complex patterns

Creative coding:

# graphics hexagon.py - Geometric art
import turtle
t = turtle.Turtle()
for _ in range(6):
    t.forward(100)
    t.right(60)

🎮 Interactive Projects Built

1. Temperature Converter

Built a comprehensive temperature conversion tool that handles Celsius, Fahrenheit, and Kelvin conversions with user-friendly menus and multiple conversion options.

2. Personal Habit Tracker

Created an interactive habit tracking system that allows users to:

Add multiple habits to track
Record daily completion status
View progress over time
Maintain streaks and motivation

3. Mini Chatbot

Developed a simple conversational bot that demonstrates:

User input processing
Conditional responses
Basic AI interaction patterns
Program flow control

4. Interactive Adventure Story

Built a text-based adventure game featuring:

User choice-driven narratives
Multiple story paths
Dynamic responses
Function-based story structure

💡 Key Learning Insights

1. Problem-Solving Approach

Break down complex problems into smaller, manageable pieces
Start with pseudocode before writing actual code
Test incrementally as you build features
Iterate and improve based on testing results

2. Code Organization

Functions are your friend - they make code reusable and maintainable
Meaningful variable names improve code readability
Comments matter - they help you and others understand your code
Consistent formatting makes debugging easier

3. User Experience

Clear prompts guide users through your programs
Error handling prevents crashes and improves usability
Feedback loops keep users engaged and informed
Intuitive interfaces make programs accessible to everyone

🔮 How This Prepares Me for Machine Learning

1. Algorithm Foundation

Control flow skills will be essential for implementing ML algorithms
Loop structures are crucial for training models and processing data
Conditional logic helps in decision trees and classification systems

2. Data Handling

File operations prepare me for reading datasets and saving results
Data structures knowledge is fundamental for working with NumPy arrays and Pandas DataFrames
Input processing skills will be needed for data preprocessing

3. Problem-Solving Mindset

Breaking down complex problems is exactly what's needed for ML model development
Testing and iteration mirrors the process of training and tuning ML models
User interaction skills will help in building ML applications and dashboards

🎯 What's Next: Module 2 Preview

With Module 1 complete, I'm now ready to tackle Module 2: Python Libraries, where I'll learn to:

Work with NumPy for numerical computing
Use Pandas for data manipulation and analysis
Create visualizations with Matplotlib and Seaborn
Apply data science techniques to real datasets

🏆 Key Takeaways

Python is powerful yet accessible - perfect for beginners entering the ML field
Hands-on practice is essential - theory alone isn't enough to build programming confidence
Building real projects accelerates learning - practical applications reinforce theoretical concepts
Foundation matters - strong Python skills will make learning ML libraries much easier
Problem-solving is a skill - it improves with practice and experience

💬 Final Thoughts

Module 1 has been an incredible foundation-building experience. Starting with simple "Hello World" programs and progressing to interactive applications has given me the confidence to tackle more complex machine learning challenges. The hands-on approach of Educative's platform has made learning Python engaging and practical.

I'm excited to continue this journey and can't wait to see how these Python fundamentals will translate into machine learning expertise. The road to becoming a Machine Learning Engineer is well-paved with these essential programming skills!

Ready to start your own ML journey? Check out the Machine Learning Engineer Career Path on Educative.com!

Tags: #Python #MachineLearning #Programming #Educative #LearningJourney #DataScience #Coding #MLCareerPath

Day 4 of Demolishing my Stack of Unfinished Projects: Secret Chat

CodenificienT — Tue, 28 Jul 2026 03:50:56 +0000

Published on Aug 21st, 2025

🚀 Made some progress

Welcome back to my "Demolishing My Stack of Unfinished Projects" series! This week, I'm excited to share the story of how I transformed a simple chat idea into a fully-featured, production-ready real-time messaging application called CodeniChat (formerly Secret Chat Bolt).

🎯 The Project That Started It All

Secret Chat began as one of those "wouldn't it be cool if..." moments. I had this idea for a secure, real-time chat application that could handle multiple rooms, user invitations, and password resets. You know the drill - you start with enthusiasm, then life happens, and suddenly it's been months with just a README file and some half-baked code.

But this week, I decided enough was enough. It was time to demolish this unfinished project and turn it into something I could actually be proud of. I started off with a short prompt into the bolt.new platform

🛠️ The Tech Stack That Made It Possible

Frontend

Next.js 15 - The latest and greatest React framework
React 19 - Cutting-edge React with the new compiler
TypeScript - Because type safety is not optional
Tailwind CSS - For rapid, beautiful UI development
shadcn/ui - Pre-built, accessible components

Backend & Database

Neon Database - Serverless PostgreSQL that scales with you
Drizzle ORM - Type-safe database operations
NextAuth.js - Secure authentication system
Bcryptjs - Password hashing and security

Real-time Features

Server-Sent Events - For real-time message updates
WebSocket-like functionality - Without the complexity

🚀 The Week-Long Development Sprint

Day 1: Foundation & Database

I started by setting up the database schema with Drizzle ORM. The beauty of using a modern ORM is that you can define your relationships once and let TypeScript handle the rest.

// Core tables for the chat system
export const users = pgTable("users", {
  id: text("id").primaryKey(),
  email: text("email").notNull().unique(),
  name: text("name").notNull(),
  password: text("password").notNull(),
  createdAt: timestamp("created_at").defaultNow(),
});

export const rooms = pgTable("rooms", {
  id: text("id").primaryKey(),
  name: text("name").notNull(),
  isPrivate: boolean("is_private").default(false),
  createdBy: text("created_by").references(() => users.id),
  createdAt: timestamp("created_at").defaultNow(),
});

Day 2: Authentication & User Management

NextAuth.js made implementing authentication a breeze. I added signup, signin, and even a password reset flow that generates secure tokens and handles the entire reset process.

The Password Reset Flow:

User requests reset → Secure token generated
Token stored with expiration → 24-hour validity
User clicks reset link → Token validated
New password set → Token marked as used

Day 3: Real-Time Chat Core

This was the fun part! I implemented the core chat functionality with:

Message grouping - Consecutive messages from the same user are visually grouped
Auto-scroll - Intelligent scrolling that doesn't interfere with user reading
Room management - Public and private rooms with automatic user assignment

Day 4: The Invitation System

One of the most requested features in any chat app - the ability to invite users to rooms. I built:

Invite modal - Select users from a filtered list
Pending invitations - Sidebar display of received invites
Accept/Decline actions - One-click room joining

Day 5: UI/UX Polish & Branding

I transformed the generic "ChatApp" into CodeniChat with:

Custom favicon - SVG-based chat icon
Responsive design - Works on all devices
Modern UI components - Using shadcn/ui for consistency
Footer addition - Copyright and "made with love" message

Day 6: Next.js 15 Upgrade

This was a significant milestone. I upgraded from Next.js 13 to Next.js 15, which involved:

React 19 upgrade - Latest React features
TypeScript improvements - Stricter type checking
Build optimization - Better performance and smaller bundles

Day 7: Deployment & Final Touches

The final day was all about getting this baby deployed:

Vercel configuration - Optimized for Next.js 15
Environment setup - Secure configuration management
Final testing - Ensuring everything works in production

🎨 Key Features That Make This App Special

1. Intelligent Message Grouping

const groupedMessages = useMemo(() => {
  return messages.reduce((groups: GroupedMessage[], message, index) => {
    const prevMessage = messages[index - 1];
    const nextMessage = messages[index + 1];

    const isFirstInGroup =
      !prevMessage ||
      prevMessage.user.id !== message.user.id ||
      message.createdAt.getTime() - prevMessage.createdAt.getTime() >
        5 * 60 * 1000;

    // Group logic implementation...
  }, []);
}, [messages]);

2. Smart Auto-Scroll

The app intelligently detects when users are reading older messages and won't force-scroll them to the bottom. But when they're at the bottom, new messages automatically appear.

3. Room Invitation System

Users can invite others to private rooms, and pending invitations are clearly displayed in the sidebar with accept/decline buttons.

4. Password Reset Flow

Complete password recovery system with secure token generation and validation.

🚧 Challenges I Faced (And How I Overcame Them)

1. Next.js 15 Compatibility Issues

Problem: The upgrade introduced breaking changes in API routes and required new Suspense boundaries.

Solution: I updated all API route parameters to use Promise<{ roomId: string }> and wrapped components using useSearchParams() in Suspense boundaries.

2. Vercel Deployment Issues

Problem: Next.js 15 peer dependency conflicts during deployment.

Solution: Used npm install --legacy-peer-deps in the build process and configured vercel.json accordingly.

3. Real-Time Message Updates

Problem: Implementing real-time features without WebSockets.

Solution: Used Server-Sent Events with a custom hook that handles reconnection and message buffering.

📊 What I Learned

1. Modern React is Incredible

React 19 with the new compiler is a game-changer. The performance improvements and developer experience are noticeable from day one.

2. TypeScript + Drizzle = Database Bliss

Having type-safe database operations eliminates entire classes of bugs. I can't imagine building a production app without this combination.

3. Component Libraries Save Time

shadcn/ui provided beautiful, accessible components that I could customize while maintaining consistency. This saved me hours of CSS work.

4. Incremental Development Works

By building features one day at a time, I was able to test and refine each component before moving to the next. This prevented the "everything is broken" syndrome.

🎯 What's Next for CodeniChat?

While this project is now "complete" in terms of core functionality, I'm already thinking about future enhancements:

File sharing - Upload and share images, documents
Voice messages - Audio recording and playback
End-to-end encryption - For truly private conversations
Mobile app - React Native version
Push notifications - For important messages

🏆 The Result: A Project I'm Actually Proud Of

Secret Chat Bolt went from being another unfinished project in my stack to a fully-functional, production-ready chat application. Here's what I accomplished in just one week:

✅ Complete authentication system

✅ Real-time messaging

✅ Room management

✅ User invitations

✅ Password reset flow

✅ Modern, responsive UI

✅ Next.js 15 + React 19

✅ Production deployment

💡 Key Takeaways for Fellow Developers

1. Start Small, Build Incrementally

Don't try to build everything at once. Pick one feature, implement it completely, then move to the next.

2. Use Modern Tools

Next.js 15, React 19, and Drizzle ORM made this project enjoyable instead of frustrating.

3. Focus on User Experience

Little details like message grouping and smart scrolling make a huge difference in how users perceive your app.

4. Deploy Early and Often

Getting your app running in production early helps identify issues you won't catch in development.

🔗 Project Links

Live Demo: [Your deployed URL]
GitHub Repository: [Your repo URL]
Tech Stack: Next.js 15, React 19, TypeScript, Neon DB, Drizzle ORM

🎉 Conclusion

Secret Chat Bolt is no longer part of my unfinished projects stack. It's a living, breathing application that people can actually use. The satisfaction of completing a project like this is incredible, and it's motivated me to tackle the next unfinished project in my stack.

Remember: Every finished project started as an unfinished one. The key is to break it down into manageable pieces and tackle them one day at a time.

What's the next unfinished project in your stack that you're going to demolish? Let me know in the comments below!

This post is part of my "Demolishing My Stack of Unfinished Projects" series, where I tackle one unfinished project per week and turn it into something I can be proud of. Follow along for more project completion stories, technical deep-dives, and lessons learned from the trenches of software development.

Tags: #NextJS #React #TypeScript #ChatApp #FullStack #WebDevelopment #ProjectCompletion #RealTimeChat #Database #Authentication

Day 3 of Demolishing my Stack of Unfinished Projects: SmartNotes Project

CodenificienT — Tue, 28 Jul 2026 03:50:49 +0000

Published on Aug 18th, 2025

The Setup: When Everything Seems Perfect

After successfully implementing a chatbot based on ChatGPT in my portfolio (as detailed in my previous "Redesign Portfolio" post), I was feeling pretty good about myself. The AI integration was working smoothly, users could ask questions about my skills and projects, and I had successfully created content embeddings that made the chatbot intelligent and contextually aware.

Little did I know that this "completed" project was about to become the perfect candidate for my "Unfinished Projects" series.

The Crisis: When OpenAI Goes Silent

It started with a simple error message: "OpenAI API account suspended." At first, I thought it was a simple configuration issue. Maybe I had accidentally exposed my API key or hit some rate limit. But after checking my environment variables and account status, I realized the problem was deeper.

My OpenAI account was suspended, and suddenly, my "completed" AI chat functionality was completely broken. Suddenly, my SmartNotes app which also powers the chat functionality went offline.

This was supposed to be a finished project. Instead, it had become the latest addition to my stack of unfinished work.

The Panic: Scrambling for Solutions

The immediate challenge was clear: either abandon the chat functionality entirely or find an alternative solution. Given that I had already invested significant time in building the user interface and database integration, abandoning it wasn't an option.

I started researching alternatives:

Claude API: Limited availability and different pricing structure
Local AI models: Required significant computational resources
Hugging Face: Promising, but I had no experience with their inference API

The clock was ticking, and my portfolio was broken.

The Discovery: Hugging Face to the Rescue

After several hours of research and testing, I discovered that Hugging Face offered inference APIs that could potentially replace OpenAI's functionality. The catch? I had to completely rewrite the AI integration layer.

This wasn't just a simple API swap - it was a complete architectural overhaul. I had to:

Replace OpenAI's embedding model with Hugging Face alternatives
Find a suitable text generation model
Handle different response formats
Implement proper error handling for a new service

The Implementation: Building Resilience

Model Selection Hell Finding the right model on Hugging Face proved more challenging than expected. My first attempts failed spectacularly:

microsoft/DialoGPT-medium - "No inference provider available"
gpt2 and distilgpt2 - Limited conversational capabilities
Qwen/Qwen3-4B - Finally worked with the nebius provider

Database Architecture Evolution The migration also exposed a fundamental issue: my MongoDB setup wasn't ideal for production use. I decided to migrate to Neon PostgreSQL, which meant:

Updating Prisma schema
Migrating existing data
Handling different ID types
Testing the new connection

Streaming Responses: The Silver Lining One positive outcome was implementing streaming text responses. Instead of waiting for complete AI responses, users now see text appear word-by-word, creating a ChatGPT-like experience that's actually better than the original implementation.

The Fallback System: Never Trust a Single Service

I learned a valuable lesson about building robust systems. I implemented a multi-layered fallback approach:

Vector Search: Primary method using Pinecone embeddings
Text Search: Fallback to simple text matching
Intelligent Responses: Pre-built responses for common queries

This ensures that even if the AI service fails, users still get helpful responses.

The Current State: Better Than Before

What started as a crisis has evolved into a more robust, scalable system. The new implementation includes:

✅ Hugging Face AI integration via Nebius
✅ Streaming text responses
✅ PostgreSQL database backend
✅ Comprehensive error handling
✅ Multiple fallback mechanisms

Lessons Learned: Why This Project Wasn't Really "Finished"

Single Point of Failure: Relying on one AI service provider is risky
Production vs. Development: What works in development might fail in production
Resilience by Design: Building fallback systems from the start saves time and maintains user experience
The Definition of "Complete": A project isn't truly finished until it can handle real-world failures gracefully

The Unfinished Projects Paradox

This experience taught me something important about my "Unfinished Projects" series. Sometimes, what appears to be a finished project is actually just waiting for the right failure to reveal its incompleteness.

The AI chat integration wasn't truly finished until it could survive the loss of its primary service provider. In that sense, the "unfinished" phase was actually a blessing - it forced me to build something more robust than I originally planned.

What's Next: The Never-Ending Journey

Even now, I'm not sure this project is truly "finished." I'm already planning improvements:

User analytics for chat interactions
Conversation history persistence
Multi-language support
Integration with more AI models

Conclusion: Embracing the Unfinished

This project taught me that "unfinished" isn't always a negative state. Sometimes, it's the catalyst for building something better than originally envisioned. The AI chat integration that almost wasn't has become one of my portfolio's most resilient features.

For developers facing similar challenges, remember: every obstacle is an opportunity to improve your architecture. What seems like a setback might actually be pushing you toward a better solution.

The journey from "finished" to "unfinished" to "better than finished" is what makes development exciting. Embrace the chaos, build resilience, and never stop improving.

Technical Stack Used:

Next.js 15.0.0
Hugging Face Inference API
Neon PostgreSQL
Prisma ORM
Pinecone Vector Database
Streaming text responses
Multi-layered fallback system

Resources:

This blog post captures the emotional journey, technical challenges, and valuable lessons learned while maintaining the honest, problem-solving tone that your "Unfinished Projects" series is known for. It shows how "unfinished" can actually lead to better outcomes!

16 Redesigning my Portfolio Website

CodenificienT — Tue, 28 Jul 2026 03:50:42 +0000

Published on Aug 18, 2025

A New Era of AI-Powered Coding Begins

I have installed Cursor on my laptop this weekend, and I am amazed at how much it speeds up my coding. I have a new debugging buddy!!

This week, I have made several updates to the Portfolio website.

The Challenge: When OpenAI Falls Short

In my previous post, I shared the excitement of implementing a chatbot based on ChatGPT for my portfolio website. The initial experience was promising - I successfully created content embeddings and integrated them with OpenAI's API. However, as many developers know, relying on a single service provider can lead to unexpected roadblocks.

When my OpenAI account encountered issues, I faced a critical decision: abandon the chat functionality or find an alternative solution. I chose the latter, embarking on a journey that would transform my portfolio's AI capabilities and teach me valuable lessons about building robust, fallback-ready systems.

The Migration: Embracing Open Source AI

The transition from OpenAI to Hugging Face wasn't just a simple API swap - it was a complete architectural evolution. Here's what I learned:

1. Model Selection Complexity Finding the right model on Hugging Face proved more challenging than expected. After testing several options:

microsoft/DialoGPT-medium - No inference provider available
gpt2 and distilgpt2 - Limited conversational capabilities
Qwen/Qwen3-4B - Perfect fit with the nebius provider

2. Database Architecture Evolution The migration also prompted a database upgrade from MongoDB to Neon PostgreSQL. This wasn't just about changing providers - it was about building a more scalable, production-ready foundation for my portfolio.

Technical Implementation: Building Resilience

Streaming Responses for Better UX One of the most significant improvements was implementing streaming text responses. Instead of waiting for complete AI responses, users now see text appear word-by-word, creating a ChatGPT-like experience:

// Streaming implementation with word-by-word appearance
const stream = new ReadableStream({
  start(controller) {
    const encoder = new TextEncoder();
    const words = response.split(' ');

    words.forEach((word, index) => {
      setTimeout(() => {
        controller.enqueue(encoder.encode(word + ' '));
        if (index === words.length - 1) {
          controller.close();
        }
      }, index * 100);
    });
  }
});

Robust Fallback System I implemented a multi-layered fallback approach:

Vector Search: Primary method using Pinecone embeddings
Text Search: Fallback to simple text matching
Intelligent Responses: Pre-built responses for common queries

User Experience Improvements

Input Focus Management Users can now have continuous conversations without losing focus:

useEffect(() => {
  if (inputRef.current) {
    inputRef.current.focus();
  }
}, [messages]);

Response Filtering Hidden internal AI processing tags for cleaner output:

const cleanResponse = response.replace(/<think>.*?<\/think>/gs, '');

Performance & Scalability

Database Optimization

Migrated from MongoDB to Neon PostgreSQL
Updated Prisma schema for better type safety
Implemented proper ID handling for vector search

API Efficiency

Reduced response times with streaming
Implemented proper error handling
Added comprehensive logging for debugging

Lessons Learned

Always Have a Plan B: Building fallback systems from the start saves time and maintains user experience
Open Source is Powerful: Hugging Face provides enterprise-grade AI capabilities without vendor lock-in
User Experience Matters: Small details like input focus and streaming responses significantly improve perceived performance
Database Architecture: Choosing the right database from the start prevents migration headaches later

Current Status & Future Plans

The chat functionality is now fully operational with:

✅ Hugging Face AI integration via Nebius
✅ Streaming text responses
✅ PostgreSQL database backend
✅ Robust error handling
✅ Clean, professional UI

Next Steps:

Implement user analytics for chat interactions
Add conversation history persistence
Explore multi-language support
Integrate with more AI models for specialized responses

Conclusion

This migration taught me that technical challenges often lead to better solutions. What started as a simple API replacement evolved into a more robust, scalable, and user-friendly chat system. The journey from OpenAI to Hugging Face wasn't just about solving a problem - it was about building something better.

For developers facing similar challenges, remember: every obstacle is an opportunity to improve your architecture and learn new technologies. The result is often a more resilient and feature-rich application.

Technical Stack Used:

Next.js 15.0.0
Hugging Face Inference API
Neon PostgreSQL
Prisma ORM
Pinecone Vector Database
Tailwind CSS
TypeScript

Resources:

This blog post captures the technical journey, challenges faced, and solutions implemented while maintaining the professional tone and technical depth that your readers expect. It also provides valuable insights for other developers who might face similar migration challenges.

15 Redesigning my portfolio website

CodenificienT — Tue, 28 Jul 2026 03:50:35 +0000

Published on Jun 21st, 2025

Thanks, NeonDB !

I just started using NeonDB thanks to their generous free tier. I have migrated the SmartNotes application to NeonDB and recreated the notes.

June 19th, 2025 Update

On Juneteenth, I started the migration process to Neon DB. I rewrote the Prisma queries and updated the database links. The app is able to generate a new Prisma client and create new tables on the remote database.

June 20th, 2025 Update

The chat application works again for the SmartNotes app. However, there are lots of error messages in the Terminal, and I am not ready to deal with those right now. Will follow up on the next post..

14 Redesigning my Portfolio website

CodenificienT — Tue, 28 Jul 2026 03:50:28 +0000

Published on Jun 20th, 2025

Currently the chat functionality on my portfolio is down because my website was probably accessed from abroad and my Open AI account got suspended.

Read the fine print

My account violated the terms of use which I did not read. I am now in the process of using some open source alternatives to get my chat functionality working again.

I also moved a few portfolio applications away from Supabase to Neon and the chat database to Neon from MongoDB. I am still relying on Pinecone to store my vector embeddings. I can see a future enhancement where I store everything in the Neon thanks to pgvector to reduce my dependencies.

June 20th, 2025 Udpate

I worked on the portfolio for a few hours today. I am trying to swap out OpenAI and replace with HuggingFace. The inference website does not seem to work because there’s a mismatch between our OpenAI embeddings and the current version of the SmartNotes app.

Recap: We created a note taking application called SmartNotes which has a chatbot. Trying to copy over the same code to my portfolio to so that both apps are using the same notes and the same database.

I will recreate the Pinecone index using a different embedding model and reconnect to HugggingFace.

13 Redesigning my Portfolio Website

CodenificienT — Tue, 28 Jul 2026 03:50:22 +0000

Published on Jan 17th, 2024

Added Chat functionality

I recently created a chatbot based on ChatGPT where I learned to create content embeddings to empower ChatGPT to chat with our data. The experience went as well as could be expected.

I have added more information from my portfolio website to the Pinecone vector store and now the same chatbot is functional on tioye.dev

Removed the Chat page

Since the chatbox is a popup window mimicking the chatbots on familiar websites, I have removed the initial placeholder chat page from the website. I have upgraded the navigation link to a button that triggers that chat window. Therefore, the Chat functionality can be triggered from any page. When the chat window is covering information on a page, the window can be closed and reopened without losing the conversation data.

Open chat

Currently, the chatbot can answer questions about my portfolio, and is based on GPT 3.5 turbo. I do not require login to use the chat. I do not anticipate many visitors using the chat functionality, and this should be good for several months

12 Redesigning my portfolio website

CodenificienT — Tue, 28 Jul 2026 03:50:15 +0000

Published on Jan 4th, 2024

The new version of the portfolio is live

I have completed the Landing, Resume and Blog pages and I have edited the domain names on Vercel to point to tioye.dev. The previous build on Vercel is officially retired.

New Landing Page, New Beginnings

The theme is light mode by default. The deployed site feels faster and there is a big button to download a PDF copy of my resume.

Next steps

Now that my updated portfolio is live, my free time going forward will be split between the AWS certification prep work, interview preparation, job applications / coding challenges, fixing the broken portfolio projects, and adding an AI powered chatbot to the portfolio.

My Newly Deployed site

My world in 2023

CodenificienT — Tue, 28 Jul 2026 03:50:08 +0000

Published on Dec 31st, 2023

A summary of the major events

Graduation: Class of 2023

The 2023 year ended on a high note for me as I have completed grad school with my Master degree in Computer Science. Before I start freaking out about job interviews, and my 6-figure student loan, it would be a great time to reminisce about the major events that have shaped the past year.

Facing deportation?

Early in January 2023, I was panicking about the registration deadline at the University of Louisville. The automated system was not allowing me to register for my classes due to the unpaid tuition balance from the previous Fall semester. Past the registration deadline, I would miss the semester, which would have several implications for my immigration status and student visa. It was a worrisome situation which was remedied at the last minute. I started classes a week late

Summer of Uncertainty

I got a 3.5 gpa during the Spring 2023 semester and was ready for my final semester. The remaining tuition balance from the Spring semester now remains to be paid. This time, there was no big check to provide to the bursar. I spent the summer trying several solutions. My income from the part time internship under the CPT was sufficient to make a small dent on the balance. I have considered selling my vehicle, but the offers were too low. The final solution came from the graduate school as they found some scholarship funds which they applied towards the tuition balance to allow me to register for my final semester. I feel fortunate about this outcome and will be empowered to pay it forward some day.

Graduated, now what?

Getting my master was the hardest thing I have ever done. There was a time that felt like everything that could have gone wrong has gone wrong. But I have persevered until I completed what I have started. I feel like if I can get through that, then I can get through anything! I am ready to go to many job interviews, until I land my first tech role. Bring it on!

11 Redesigning my portfolio website

CodenificienT — Tue, 28 Jul 2026 03:50:02 +0000

Published on Dec 29th, 2023

Enter TypeScript and Next.js 14

I am continuing the process of visually overhauling my portfolio website. A few weeks after upgrading my site to Next.js, I have started using TypeScript for my web applications. I have spent the Fall semester finishing my master's degree, and contemplating several ways I can improve my portfolio website.

I am now a recent graduate applying for my first full-time role in tech, and upgrading my portfolio site to TypeScript along with several visual improvements is a must.

Old Version

New Version

New Version with Dark Mode

I have added a dark mode toggler to the improved navigation bar and I am planning to remove a few pages. I plan to add a chat page based on a vector database of my bio so users can chat with my data.

Another noteworthy improvement is that the inclusion of TailwindCSS has reduced my coding time dramatically. It took me a week to get the main user interface working last time. This time, less than an hour. I already feel like a 10x developer :)!

Coming Soon!

For now, I am deploying the new version of my portfolio on a separate vercel endpoint https://tioyedev2024.vercel.app/ and my website https://tioye.dev/ still points to previous build. I plan to make the switch once the 3 main pages, Landing, Resume and Experience, are deployed on the new endpoint

10 Redesigning my portfolio app

CodenificienT — Tue, 28 Jul 2026 03:49:55 +0000

Published on Mar 16th, 2023

Hashnode connected

Today I followed the incredibly useful blog post by CatalinPit and I connected my portfolio blog directly to Hashnode, skipping GraphCMS. This negates the need to create a duplicate post in GraphCMS after posting on Hashnode.

Revalidate: 600

I have kept the default refresh period in Vercel to 10 minutes. New blog posts on Hashnode will show up on my portfolio within 10 minutes, provided the Vercel platform rebuilds the new page in sub-30 seconds as usual.

GitHub actions untouched

I have not messed with anything I have already set up in GitHub. My latest blog should be synched to my GH profile every sunday as usual

One caveat

The GraphCMS version of my blog was based on blog series which are almost mirrored from Hashnode. Unfortunately, the Series feature was glued onto Hashnode after the fact and the GraphQL API does not support fetching blogs based on blog series. I have attempted a simple fetch to grab the blog series, but I was getting error messages. Currently, I have removed the blog series header from the portfolio site. I have replaced the series badge on each blog post with an avatar of the author, aka, yours truly!