Forem: Maame Afua A. P. Fordjour

I Got Lost in Canary Wharf for 30 Minutes, But I Found the Future of SRE

Maame Afua A. P. Fordjour — Thu, 12 Mar 2026 17:15:04 +0000

If you've ever been to Canary Wharf, you know it's less of a business district and more of a high-stakes escape room designed by someone who really dislikes Google Maps.

I arrived for SRE Day London 2026 at the Everyman Cinema feeling prepared. I had my bag, my notes, and a general idea of where I was going. Fast forward 30 minutes, and I was still wandering around Crossrail Place like a lost protagonist in a sci-fi movie. Between the multiple levels and the "Level -2" hidden entrance, the frustration was real. I spent nearly half an hour pacing back and forth, trying to figure out how to actually get into the venue. Honestly speaking I probably hit 2k on my daily steps from walking around in circles to find the exact location. And for some weird reason, google maps and apple maps don't work really well in Canary Wharf, did some research. Apparently it is due to something called The urban canyon effect. If you are interested in reading more about how that affects GPS signals, you can read this article: urban canyon

But honestly? The second I stepped inside, the frustration evaporated.

The Swag Haul

First things first: the swag. As a student, you quickly learn that the quality of an event is often proportional to the stickers on the table. SRE Day did not disappoint. I loaded up on fridge magnets and stickers, but the highlight was definitely the SRE Day t-shirts. I managed to cop one, and let's just say it's going straight into my weekly rotation.

The Knowledge Drop: Morning to Midday

The talks kicked off at 09:00, and sitting on those comfortable Everyman sofas made it feel more like a movie premiere than a tech conference. Here is a breakdown of what I learned before 15:00:

Peter Marshall (Imply): He opened with a keynote on Decoupled Observability. The big takeaway here was that we are often limited by "tightly coupled" architectures where data is stuck to specific tools. By decoupling the data layer, we can scale our detection and investigation without the costs spiralling out of control.

Dewan Ahmed (Harness): He talked about Secure by Default in AI-driven delivery. As we move faster with AI, we run the risk of "automating insecurity at scale." He challenged us to look beyond just scanners and build confidence directly into the pipeline.

Matt Henderson (Phoebe): This was fascinating he compared software reliability to the human immune system. Instead of just reacting to alerts and scrambling when things break, we need systems that can predict and prevent failures, just like our bodies handle threats before we even feel sick.

Tyler Hannan (ClickHouse): He asked a controversial question: Do Metrics Matter? While metrics are the fastest way to see if a system is unhealthy, Tyler pointed out that as systems get more complex, metrics alone aren't enough to understand the "why" behind unpredictable failures.

Birol Yildiz (ilert): He showed AI SRE in action. We're moving toward a world where AI agents can diagnose and remediate outages autonomously. Imagine an incident fixing itself without anyone getting paged at 3 AM!

Lunch and the Afternoon Sprint

After a much-needed pizza break (shoutout to incident.io for powering that!), we dove into the afternoon sessions:

Deniz Yalcin & William Ravensbergen (ING): They reminded us that reliability starts with Customer Data. In banking, if upstream data is malformed or delayed, everything else fails from fraud prevention to user trust. It's an underrated SRE dependency.

Adriana Villela (Dynatrace): She emphasized that Observability is a Team Sport! We often fall into the trap of creating "Observability Silos" just like we did with DevOps. To succeed, observability needs to be integrated across the whole organization, not just a single team.

Heather Thacker (Gatling): She broke down the Performance Testing Arsenal. It's one thing for your app to work on a laptop, but another to handle 10x traffic during a marketing campaign. She covered load, stress, and soak testing—essential tools for any SRE.

Tasmia Niazi: This session was super relatable for me. She shared her journey from learner to leader, explaining that SRE is a mindset and a culture, not just a job title. Adopting that state of mind is what builds resilient teams.

Getting Involved: Tracer Cloud and Open Source

During the networking and sponsor crawl at 14:30, I had the coolest discovery: Tracer Cloud's Open SRE Agent. It's a tool focused on cloud-native alert investigation, using AI to figure out root causes before humans even have to step in.

Because I've been looking for ways to get more "hands-on" experience, I officially signed up to be a contributor! If you want to jump in and contribute to the repo as well, you can find it here:

Tracer-Cloud / opensre

Build your own AI SRE agents. The open source toolkit for the AI era ✨

Open SRE — Build Your Own AI SRE Agents

An open-source framework so you can build AI-powered SRE agents that automate incident investigation and root cause analysis. Plug in the alerting sources you already use (Slack, Grafana, Datadog, PagerDuty and more), and compose custom workflows tailored to your infrastructure

Slack · Getting Started · Tracer Agent · Docs · FAQ · Security

Quick Start

git clone https://github.com/Tracer-Cloud/open-sre-agent
cd open-sre-agent
make install
make install-hooks
cp .env.example .env
# run opensre onboard to configure your local LLM provider
# and optionally validate/save Grafana, Datadog, Slack, AWS, GitHub MCP, and Sentry integrations
opensre onboard
make local-grafana-live

Choose a Path

Local Grafana RCA Demo Run Tracer against a real local Grafana + Loki stack and get a first RCA report with one command Start here: Local Grafana RCA Demo
Bundled Local RCA Demo Skip Docker and run a bundled alert plus bundled evidence fixture…

View on GitHub

Contributing to open-source is one of the best ways to move from theory to reality.

What's Next?

Despite the 30-minute maze-running session at the start, SRE Day was a massive win. I came for the t-shirt, but I left with a contributor invite and a much clearer picture of where the industry is heading.

If you are curious about cloud or have deep interests in reliability, it doesn't matter if you're not in London! They host events all around Europe. You should definitely subscribe to their page on Luma to check out their upcoming events.

Also, if you're looking to give back, they have an option to help out as a Community Hero! It's a great way to support the ecosystem while growing your own network.

Now, if someone could just build an agent to help me navigate Canary Wharf next time... that would be great because honestly, I became Maame 'the explorer' in those 30 minutes😂.

DevOps From Scratch: Entry #05

Maame Afua A. P. Fordjour — Sat, 07 Mar 2026 16:39:39 +0000

Chapters 6 and 7 of the Linux Foundation LFS101 course cover System Configuration from the Graphical Interface and Common Applications. On the surface, these sound like the "not-so-technical" chapters, the ones you skim to get to the real stuff.

But I actually found them more useful than I expected. Here's why.

Chapter 6: System Configuration from the Graphical Interface

After all the kernel talk and boot process deep-dives from previous entries, this one felt like a breather. It's about what you can configure directly through the Ubuntu desktop, no terminal required.

Display, Date & Time Settings are all inside GNOME's Settings panel, just like you'd expect. But one thing that caught my attention was the NTP (Network Time Protocol) option for syncing time automatically. In DevOps, this actually matters. If multiple servers disagree on the time, your logs won't line up and debugging becomes a nightmare. So even "setting the clock" has a real professional reason behind it.

Network Manager is what Linux uses to handle all your connections: WiFi, ethernet, VPNs. The GUI version lives in your top-right taskbar and does a lot of the heavy lifting automatically. The insight the course gives though is that everything you configure through that GUI maps to a config file underneath. The GUI is the training wheels. Knowing what's behind it is what matters for DevOps.

Installing and Updating Software the course clears up a distinction I was fuzzy on:

sudo apt update    # refreshes your list of available packages (installs nothing)
sudo apt upgrade   # actually downloads and installs newer versions

Always run update before upgrade. Now I properly understand why. ✅

Chapter 7: Common Applications

This chapter is a guided tour of the Linux app ecosystem. The apps work great, they just have different names to what you're used to.

Internet & Communication

Need	Linux App
Web browser	Firefox, Chromium
Email	Thunderbird, Evolution
File transfer	FileZilla
Messaging / VoIP	Pidgin, Ekiga

Nothing groundbreaking, but good to know your way around.

Productivity & Dev Tools

LibreOffice is the open-source Microsoft Office. Writer, Calc, and Impress cover Word, Excel, and PowerPoint respectively. It even reads .docx and .xlsx files. Won't need it much for DevOps, but it's there.

On the dev side, Linux is properly in its element: gcc for compiling, gdb for debugging, Eclipse or VS Code as an IDE, and of course git for version control, which was also created by Linus Torvalds. The man really said "I'll just build Linux AND the version control system while I'm at it." 😂

Multimedia & Graphics

VLC needs no introduction, it plays everything, everywhere, always. Audacity covers audio editing, Kdenlive handles video editing, and GIMP is the open-source Photoshop alternative that's been around since 1996. Inkscape handles vector graphics too (think open-source Illustrator).

The full ecosystem laid out like this is honestly impressive. There's a free, open-source alternative for basically everything.

The One Big Takeaway

Linux is a complete operating system, not just a terminal with some files floating around it.

Everything in the GUI maps directly to a config file or CLI command underneath. Using the desktop to set things up is fine. Knowing what's happening underneath is what separates someone who uses Linux from someone who understands it.

That's the gear I'm trying to shift into. Slowly but surely.(Just like the way penguins walk)

P.S. I've updated Flashy with a new deck for both chapters, go test yourself if you've been following along!

What's Next?

Command Line Operations we're leaving the desktop behind and going full terminal. Nervous and excited in equal measure. See you in the next one!

How My "Illegal" Visit to Tech Show London Turned Into a Summer Internship Win

Maame Afua A. P. Fordjour — Thu, 05 Mar 2026 01:04:10 +0000

I officially became a "Tech Outlaw" today. 😂

Don't worry I didn't do anything malicious. I just happened to be in the right place at the "wrong" time. This year, I made a personal vow to stop being such an introvert. I decided to move past the workstation in my room and actually see the opportunities waiting in the real world. When I saw the "Tech Show London" flyer on Instagram, specifically mentioning DevOps, Cloud, and Infrastructure, I knew I had to be there.

I registered, showed up for Day One, and that’s where the adventure (and the "crime") began.

Part 1: The "Accidental" Infiltration

Yesterday morning at the ExCeL was electric. Hundreds of people were streaming in, multiple shows were running simultaneously, and in the chaos, I simply scanned my badge and sailed through the gates. I spent the first few hours feeling like a total pro, soaking up the atmosphere and jumping between the Cloud and DevOps keynotes.

I was taking frantic notes, thinking, "This is it. I’m finally in the room where it happens." Three major "lightbulb" moments hit me:

The Cloud-Native Shift: It’s no longer about just "using" the cloud for storage; it’s about architecting systems specifically for it so they can scale at the speed of light.

The Human Side of DevOps: A speaker hammered home that you can have a perfect Docker or Kubernetes setup, but if your team’s communication is broken, your tech stack won't save you. DevOps is a culture, not just a toolkit.

The "Headache" Economy: Walking the floor, I realized why thousands of tech firms exist. One solves security, one solves speed, one helps find bugs—every booth is there to cure a very specific "headache" for a developer.

I even cornered one of the keynote speakers afterward. I told him I was an aspiring DevOps engineer, and he gave me invaluable advice on what to prioritize in my studies. To top it off, I managed to secure a CPD (Continuing Professional Development) certificate for the sessionssomething I didn't even know existed!

Part 2: The "Bathroom" Blunder

Everything was going perfectly until I needed the restroom. I walked up to a security guard for directions, and she took one look at my badge, then looked at me, and her eyebrows shot up.

"Wait a minute... you're a student?" she asked.
I gave her a massive, confident smile. "Yes, I am!"
She let out a laugh and shook her head. "Honey, you aren't supposed to be here until tomorrow at 2 PM! Students are Day Two only."

And just like that, my "illegal" residency at Tech Show London came to an end. I was politely shown the exit, but I wasn't even mad. I already had the notes, the speaker's advice, and my certificate in hand.

I was exhausted from studying for an exam next week and considered going home for a nap. But then, a reminder popped up on my phone: a DevOps Meetup I had totally forgotten about. Despite the fatigue, I decided to push through.

Part 3: The Pivot to "Data’s Revenge"

The meetup was "DevOps Next Generation: Data’s Revenge" hosted by Fivium, Tarmac, and CODER at Adam Street.

If I hadn't been kicked out of the ExCeL, I might have missed this entirely, and that would have been a tragedy. The energy was completely different more intimate and way more focused. I listened to Beverly Clarke MBE and Darko Klincharski drop gems about the industry, it was quite interesting to listen to how much money companies pay to use cloud services, the figures were massive! and mind blowing.

After the keynote, realising I was the only student there, surrounded by all these platform engineers, DevOps engineers and even CTO's and hiring managers, I decided to take a huge risk. During the session, I stood up and asked:

"Is there anyone here looking for an intern who is incredibly keen to learn about DevOps and ready to work to gain experience?"

The room went quiet for a second, and then everything changed. One of the key speakers told me to leave with 6 networks here and even mentioned there were hiring managers in there with us. They all looked at me and smiled and told me to come see them after the keynote!

As soon as the keynotes ended and the pizza and drinks started flowing, I was swarmed. I didn't need to send a single CV or give my GitHub. Instead of being "Applicant #452" in an automated system, I was a real person having a conversation over a slice of pizza. By the end of the night:

Two companies offered me the opportunity to come in for the summer to pair program and learn the ropes of DevOps.

I connected with a start-up that wants me to grow alongside them as they build their infrastructure.

I ended up connecting and taking advise from people who had been in the DevOps job role for years, coolest thing was taking advice from a platform engineer that had been in the game for 30 plus years! He mentioned to me how during his time, he had to write code on physical pieces of papers, imagine!

My final thoughts are, Never be afraid to use your voice or put yourself out there. You truly never know who is watching. I now have a summer internship secured just from a conversation over pizza. I didn't have to wait for three rounds of interviews or an HR algorithm to "pick" me.

Opportunities pop up when you are actively searching. I'll definitely keep showing up in these tech spaces legally or otherwise! 😉

Gemini Mechanic: Fixing Your Gadgets with AI

Maame Afua A. P. Fordjour — Mon, 02 Mar 2026 21:39:32 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I created a project called Gemini Mechanic. It is a smart assistant that helps people fix broken hardware and electronics. Many people feel lost when a gadget stops working. My web app lets users take a photo of the problem or type a description to get help right away.

Google Gemini is the brain of this project. It looks at the photos to figure out what is wrong. Then it gives the user a list of repair steps and tells them what parts they need to buy. This makes it much easier for regular people to repair their own things.

Demo

GitHub Repo

I previewed it and realised the embedded version doesn’t allow the camera to be used so you can just access the live link here:

Live demo

In my demo, I used my broken iPhone 8 as an example. The app was able to recognize the phone and see that the screen was detached. It provided a full repair guide. It included steps to turn off the power and remove the ribbon cables safely.

What I Learned

One of the biggest lessons I learned was about mobile design. Most people are not at a desk when they are trying to fix something. They are usually holding their phone while they work. I spent a lot of time making the app mobile responsive so it looks good on small screens.

I also learned how to write better instructions for the AI. For repairs, safety is the most important part. I had to make sure Gemini always reminds users to do things like disconnect the battery before they start working.

Google Gemini Feedback

Working with Gemini was a good experience, but I did face some challenges:

Picking the right model: I spent a lot of time testing different Gemini models. I needed one that was smart enough to recognize small parts but fast enough to work on a phone. I don’t know why whenever I try to use Gemini as the ai for any of my projects, I always run into errors. But with the project I was pushed to figure it out, took me a couple of hours till I found the best model to run it with.
Mobile speed: Making sure the app stayed fast while the AI was thinking was tricky. I had to optimize the code so the user experience stayed smooth on mobile devices.

Open Source
I want to make this project open source so everyone can use it. If you have ideas for new features or want to add more repair data, please feel free to contribute to the GitHub repo. I would love to see what we can add to make it better.

Know Your Rights, Find Your Support — Built for Brent

Maame Afua A. P. Fordjour — Sun, 01 Mar 2026 19:52:26 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Brent is one of London's most diverse and deprived boroughs. 340,000 residents. 130+ languages spoken. A 27% child poverty rate, one of the highest in the capital.

The people who live here are not short of resilience or community spirit. What they are often short of is information. Not because it doesn't exist but because it's scattered across dozens of council web pages, NHS portals, charity websites, and government guidance documents, written in bureaucratic language, rarely updated, and almost impossible to navigate under stress.

When someone is facing eviction tonight, they don't have time to search five websites. When a young person gets stopped and searched, they should already know their rights. When a resident doesn't know there are fully funded training courses available to them for free — that information gap has a real cost.

I live in Brent. I built this for my neighbours.

What I Built

Brent Navigator is a free, community webapp that puts verified, plain-English information in one place, organised around the moments that matter most to residents.

Nine sections covering the full range of issues Brent residents face:

Crisis Support — Mental health lines, domestic abuse contacts, emergency services
Health — NHS urgent care, GP registration, healthy living support
Housing — Renting rights, social housing bidding system, eviction process, emergency housing
Employment — Free job search tools, fully funded training courses, benefits explained, starting a business
Cleaner Brent — Bin collection finder, fly-tipping reporting, bulky waste options
The Hub — Community groups, local events, faith organisations, local news, and an interactive Leaflet.js map with 17 clickable location pins across the borough
Youth & Rights — Stop and search rights, education entitlements, mental health support, care leaver entitlements
Tax & Budget — Council tax discounts, where the money goes, accountability tools, financial help
Council FAQs — A searchable accordion of 32 verified answers to the most common resident questions

Every phone number is real. Every link goes somewhere useful. Every piece of content was verified against official sources.

Demo

Live app: brent-navigator.vercel.app

GitHub: github.com/Maame-codes/brent-navigator

Dashboard

Tabs on the different help available

Interactive Map featuring places in Brent

How I Built It

Stack:

React + Vite
Framer Motion for page transitions
Leaflet.js for the interactive map
CSS custom properties for theming
Deployed on Vercel, source on GitHub

The content was the hardest part.

Every section required genuine research, verifying phone numbers against official sources, checking council policy documents, confirming addresses. The Housing section alone covers the Locata bidding system, Section 21 validity checklist, illegal eviction law, deposit protection rules, and emergency housing routes. That's not content you can make up or guess at. People will use this in real situations.

The CSS nearly broke me.

I'll be honest, my CSS sucks. It was the reason why I never wanted to ever get into front-end anyway and getting this to be responsive was a battle. So forgive me if it is not the most aesthetically pleasing site there is, I TRIED MY BEST 😂. The sidebar needed to become a hamburger menu on mobile without pushing or shifting the main content. The interactive map needed to render correctly on small screens. The tab navigation inside each section needed to wrap without breaking the layout. I spent significant time wrestling with position: fixed, overflow-x: hidden, -webkit-overflow-scrolling: touch, and overscroll-behavior to get the mobile experience feeling smooth and native. It's not glamorous work but it matters — most Brent residents access the internet on a phone.

The tab persistence was a small detail that mattered a lot.

Early on, refreshing the page would always kick you back to the dashboard. For an app that residents might bookmark and return to repeatedly, that's genuinely frustrating. I added localStorage to persist the active tab across sessions so the app remembers where you were.

Why I built it this way.

I could have built a simple link directory. Instead I chose depth real explanations, real context, real phone numbers. The Housing section tells you that you don't have to leave just because you receive an eviction letter. The Youth section tells you exactly what an officer must say before a stop and search. The Benefits section explains the Universal Credit taper rate in plain English so residents aren't scared to take a job.

That's the difference between a directory and a navigator. This is built to help real people, and solve real problems in a neighbourhood I live in.

Built with ❤️ for the 340,000 residents of Brent, London.

I Left My First Hackathon at 8 PM — And it Was a Massive Success!

Maame Afua A. P. Fordjour — Sun, 22 Feb 2026 13:55:12 +0000

Most hackathon stories start with "We stayed up for 36 hours and drank 10 Red Bulls."

Mine is different. Yesterday was Day 1 of my first-ever hackathon, Hack London (HackLDN). By 8 PM, I was heading for the exit. I didn't finish the project, and I didn't stay for the midnight games and karaoke (I did get a really nice chicken burrito, lots of snacks & drinks & also pizza(^///^)).

Yet, I walked away with two recruiter contacts, a laptop covered in cool stickers, and a realization about the global dev community that surprised me. Here is why every aspiring developer needs to stop worrying about "finishing" and just start showing up.

They tell you hackathons are 24-hour marathons fueled by caffeine, Red Bull, and zero sleep. They tell you that if you aren't there when the sun comes up, you haven't "really" attended.

They’re wrong. I am sure people who have never been to hackathons probably think to have to close your eyes and be able to code something that wins you a prize. Absolutely not!

I made sure I went to the premises early, that was when most people network and try to find teams. The people I spoke to during that period, I would say 30-40% of them actually had no coding experience, just curious minds.

So you don't have to be a coding expert to go for these things. Some go to find co-founders, others go for the free food(no kidding, one guy told me this when I went to grab coffee😂'I am just here for the stickers and free food'...well fair enough😂😂), others just go to learn too out of curiosity. I was definitely in that learning category, I always say you never know what you can learn in these type of events.

Yesterday, I walked into Hack London as a first-timer with a laptop, a copy of my CV (obviously), and a lot of nerves. In those few hours, I gained more than most people do in a full weekend of coding. Here is why Day 1 of my first hackathon was a total game-changer.

The "Sticker-Clad" Reality

Walking into the venue, the energy is infectious. You see the "HACKER" badges, the lanyards, and the immediate race to claim a spot. My laptop is now officially part of the community, sporting fresh stickers from Google DeepMind, ElevenLabs, PyCharm and MLH. (Didn't spare my nintendo switch, she also got one of Hack London's stickers on her hehe)

But beyond the swag, there was a deeper realization: I was finally in the room where things happen.

The MLH x Dev.to Connection

One of the coolest parts of the day was meeting a representative from MLH (Major League Hacking), Quinn was super nice and very supportive big-ups to him fr （￣︶￣）↗　, he answered every single question and was always ready to help. I actually first heard about MLH because of their recent acquisition of Dev.to. It felt like a "full circle" moment to be at an MLH event while being a fan of this platform.

But here’s the kicker: While talking to other hackers, I realized that a huge number of people in the UK dev scene haven't discovered Dev.to yet! It seems to have a massive footprint in the US, but over here, it’s still a bit of a "hidden gem." If you're reading this from the UK, welcome to my favourite corner of the internet!

The "Early Exit" Dilemma

I teamed up with a group of talented people, and we started getting to know each other and thinking of a project. The ideas were flowing, the GitHub repo was initialized, and the vibes were high.

Then came 8 PM. I had other commitments I couldn't move, and I had to make the tough call to step away. Even though I couldn't cross the finish line with my team, the hours spent collaborating taught me more about real-world team dynamics than any solo project ever could.

Skipping the "Black Hole" of Job Portals

If you're a student, this is the real secret sauce of HackLDN or any hackathons in general. There were recruiters on-site who were actually hiring.

If you're a student, you know the pain: uploading a CV to a portal and never hearing back.

At HackLDN, I got to bypass the "AI gatekeepers." I met actual recruiters who were hiring. I didn't just "apply", I looked them in the eye, sent them a copy of my CV, and had a real conversation. That 5-minute human interaction is worth 100 LinkedIn "Easy Applies."

Final Thoughts: Just Go

If you’ve been holding back from your first hackathon/ any other thing in general because you don't think you're "good enough" or can't stay for the full 24 hours just go anyway.

Show up for Day 1. Grab the stickers. Talk to the sponsors. Meet the MLH reps. Hand over your CV.

You don't need to pull an all-nighter to jumpstart your career. You just need to be in the room.

Suffering from BUGS: How I Almost Deleted My Entire Project

Maame Afua A. P. Fordjour — Thu, 19 Feb 2026 03:23:34 +0000

You know that iconic DJ Khaled album, "Suffering from Success"? The one where he looks overwhelmed by how much he's winning?

Yeah... I WISH that was me.

For the last 48 hours, I wasn't suffering from success. I was Suffering from Bugs. Specifically, the kind that make you question if you should drop out of Computer Science and just become a farmer instead.

I spent two days staring at a screen that screamed 500 Internal Server Error and ModuleNotFoundError. I was winning on localhost:3000 (it worked perfectly!), but the moment I tried to deploy? Disaster.

Here is the story of how I almost deleted my entire project out of frustration, and how I turned a 45-second nightmare into a win

1. The "Works on My Machine" Trap

I think everyone who codes in general has faced this trap maybe one too many times in their life. The reason I decided to build this project in the first place was because I have an upcoming quiz worth 30 marks of my final grade in a couple of weeks, and looking at 80+ slide per every week's lecture would be a nightmare for my revision. I do write notes (in my own words for better understanding) but when it gets to the last minute, I still cannot go through all my notes to refresh my memory of 200+ slides or even more for half of my semester. Then I decided to build 'SlideSift': Very simple tool that basically summarizes your lecture notes, just for revision.

Some of us including myself, are slow learners, and I struggle to just read or study something once, for it to stick forever. People with those kind of abilities are so lucky! But if you are like me, this would actually help you in your uni studies.

I built it using Google Gemini Pro. On my laptop, it was beautiful. It felt like magic.

But then I tried to deploy it to Render.

The Reality Check:

Cloud servers are not your laptop. They don't care that "it works for me."

My requirements.txt was a mess. The server installed an ancient version of the AI library that didn't even know what "Gemini" was.

Lesson Learned: If you don't lock your dependencies (e.g., google-generativeai>=0.8.3), the cloud will humble you very quickly.

2. The 45-Second Awkward Silence

The perfect scenario of how I was feeling whiles waiting for the web app to summarize the notes I uploaded, is very similar to those times when DVD's were a thing, you insert the disc into your DVD player, and sometimes if its corrupt, it shows 'disc error'. Or for my gamers, if any of you ever used the Nintendo GameCube, sometimes when you insert the tiny disc, it takes like 2 mins to load and gives you an error, then while it loads, you pretend to look into the sky so it loads faster... 😂only to receive an error and all you feel is disappointment.

Anyway, back to the story:

Once I finally fixed the crash (after what felt like 50 deploys), I hit the next wall: Latency.

Gemini Pro is smart, but it is slow.

I would upload a PDF, click "Summarize," and then... wait.
And wait.
And wait.

It took 45 to 60 seconds to get a response (Honestly speaking I think at a point it took like a solid 3 mins to even end up giving me an error).

Gemini pro took 45 to 60 seconds to summarize a single PDF. Then I tried to change it to Gemini Flash 1.5, for some weird reason I crashed the app when I used the Flash version, it didn't work at all.

Imagine showing this to a recruiter:

Recruiter clicks "Summarize"
... spinner spins ...
... awkward silence ...
... "So, how's the weather?" ...
... still spinning ...

Or people even using this, with modern technology in 2026, no one would wait 3 mins for a web app to work, let's be honest here. Even me the creator, didn't want to wait that long!

I hated it. It felt broken. I seriously considered hard-coding a loading message that said: "Go make a coffee, this will take a while."

This is when the Imposter Syndrome kicked in hard. I thought, "Real engineers build fast apps. I built a loading screen simulator."

3. The Pivot: Choosing Speed (Groq)

I realized I didn't have a Code problem; I had an Architecture problem.

I didn't need the "smartest" model in the world (Gemini Pro) to summarize a PDF. I needed the fastest one.

I scrapped the Google integration and switched to Groq (running Llama-3).

Groq is an inference engine designed purely for speed.

The result?

Before: > 50 seconds.

After: < 30 seconds.

It was instant. I clicked the button, blinked, and the notes were there. I literally screamed. I had been sitting behind my PC for hours, just surviving on zero sleep, dried mango slices (love them) and iced americano just to stay awake to make it work.

4. Why I Didn't Quit (The DevOps Mindset)

Well I did almost delete the entire repo and the project itself, because I kept on having so many deployment issues and Render kept on sending these error messages to my mail:

I got almost 20 of these messages and that was the time I almost gave up on this. But when I was staring at those error logs, wanting to delete the repo, I realized something: This IS the job.

As a CS student, I love writing code. But as an aspiring DevOps engineer, my job isn't just to write code, it's to ship it.

Fixing the requirements.txt? That's Environment Management.
Switching from Gemini to Groq? That's System Design.
Handling the "Cold Start" on the free tier? That's Cost Optimization.

Honestly, that's why I am always heavy on building as you learn, because truly, that is the only way to make it stick. If I am to work on another project and face these issues, I would immediately know what to do. Tech is so fascinating, you will lose your mind sometimes but its truly remarkable.

The Result

Slide Sift is now live. It turns chaotic lecture slides into pristine study guides instantly.

Try it here (Live Demo)
(Note: It’s on the free tier, so give it at most 50s to wake up the first time!)

Check the code on GitHub

To anyone stuck in "Deployment Hell" right now:

Don't delete the repo.
Take a walk. Drink some water/ coffee for my coffee lovers 😉. CRY IF YOU HAVE TO

The error is probably just a missing environment variable. You got this. 💙

DevOps From Scratch: Entry #04

Maame Afua A. P. Fordjour — Wed, 18 Feb 2026 15:17:54 +0000

When I first started my Linux journey, I had this image in my head of a dark room, green text scrolling at light speed, and a keyboard-only lifestyle. I thought if I didn't spend every second in a terminal, I wasn't doing it right.

But as I dug into Chapter 5 of my training (just a reminder that I am using the Linux Course from the Linux Foundation (personal preference)), I realized something cool: Linux isn't just a command-line tool. It actually has a very sophisticated graphical side. Learning how the screen you look at actually works—from the login page to the windows you drag around made the whole system feel a lot less intimidating.

Here is what I learned about the visual side of Linux.

1. The Engine Behind the Screen

In many operating systems, the desktop is built directly into the core system. In Linux, the graphical interface is more like an "app" that runs on top of everything else. There are two main engines that make this happen:

X Window System (X11): This is the old-school veteran. It’s been around for decades. One neat trick it has is the ability to run a program on one computer but show the window on a totally different screen over a network.
Wayland: This is the new kid on the block. It’s designed to be faster, smoother, and more secure than X11. Most modern versions of Linux are switching to this now.

2. Desktop Environments vs. Window Managers

People often get these confused, but they do different jobs:

Window Manager: This is a small program that handles just the basics—the borders of your windows, the buttons to close or minimize them, and moving them around.

Desktop Environment: This is the whole package. It includes the window manager plus the taskbar, the file folders, the settings menu, and even the wallpaper.

GNOME: Very clean and modern. It’s what you usually see on Ubuntu.

KDE Plasma: If you are moving from Windows, this will feel very familiar. It is super easy to customize.

XFCE: This is great if you have an older laptop because it doesn't use much power or memory.

3. The Login Gatekeeper

That screen where you type your password when you first turn on the computer? That is called a Display Manager. Its only job is to check who you are and then start up your favorite desktop environment.

4. The Magic Escape Hatch (TTY)

This is probably the coolest pro tip I found. If your screen ever freezes and your mouse won't move, you aren't stuck! Linux has hidden text-only screens called Virtual Consoles or TTYs.

You can jump between them using keyboard shortcuts:

Ctrl + Alt + F3 (through F6): These take you to a purely black-and-white text screen. You can log in here and fix things using commands if the visual part of the computer breaks.

Ctrl + Alt + F2 (or F1): This usually jumps you right back to your normal desktop.

Why Learn This for DevOps?

You might wonder why a DevOps student needs to care about desktop icons. Even though most servers we manage don't have a screen at all, knowing how these layers work is helpful. It helps you set up your own laptop for work and understand how to "forward" a visual app from a server to your own computer when you need to run a specific tool. And also I have a strong believe that it is always good to master the basics (foundations) of anything you want to learn deeply.

P.S for my flash card buddies, I updated Flashy, just to refresh your memory :)

Nike Was Right: The Only Coding Advice You Actually Need

Maame Afua A. P. Fordjour — Mon, 16 Feb 2026 13:03:45 +0000

I am pretty sure anyone who opens this would wonder what a shoe brand has got to do with coding? But just hear me out on this one. Let me start by saying a story that even led to me writing this in the first place.

I spent about three hours yesterday staring at a blank VS Code window on my pc. Well I was not literally staring at it for three hours because that would be a bit psychotic. I had my VS code opened and I was ready to work on a project I had in mind.

But a friend sent me a TikTok video and I made the mistake of opening it. I read the comments and laughed for about 15 minutes. TikTok comments are actually always funnier than the videos themselves. Anyway I ended up just doom scrolling on TikTok for about three hours and then switching through my social media apps. I then just got bored of everything and realized that I had successfully wasted my time. I then asked myself what I was even looking for. I could have used that time for something extremely productive.

The Trap of Waiting to be Ready

We look at what experts are doing and we feel small. We think we need to be perfect before we even type our first line of code.

But while we are waiting to feel prepared, the time just slips away. This kind of overthinking is the biggest thing that slows us down. We are not actually researching. We are just procrastinating because we are afraid to fail.

This is how procrastination slows us down. We overthink everything and we wait for a feeling of being ready that never actually comes. We think we need to watch one more tutorial or read one more article. But while we are waiting, we are just standing still. And standing still is not a good thing, because as you are standing still, some are crawling, others walking slowly, some walk briskly and most are running.

The Nike Philosophy

I started thinking about that famous Nike slogan lately. "Just do it".

It sounds simple, but it is actually the best coding/ life advice ever. In the world of tech, we often try to learn everything before we do anything. We want to master Python and Git and every other tool before we build a single thing.

The truth is that you only learn by doing. You do not learn to swim by reading a book about water. You have to jump in. Coding is exactly the same.

You learn when your code breaks.
You learn when you spend an hour fixing a weird path error.
You learn when you finally make that first messy commit.

The Cost of Overthinking

If you wait until you feel like an expert, you will wait forever. Procrastination is just a fancy way of saying you are afraid.

Just getting up to do something is what actually gets the job done. Doom scrolling and overthinking will only make you feel worse.

I am learning that it is okay to be confused. Most of us are just Googling things as we go anyway. I don't know who needed to hear this but if you are like me and you procrastinate a lot, JUST DO IT anyway. And you will eventually get better at whatever it is :)

DevOps From Scratch: Entry #03

Maame Afua A. P. Fordjour — Wed, 11 Feb 2026 07:19:34 +0000

After installing Ubuntu on my laptop mainly for this linux learning journey, I left it there for about almost two weeks (not my fault! had to focus on some uni work). I am continuing my journey through the Linux Foundation course, for the DevOps from Scratch journey. Today I am looking at chapter 4. This chapter is about how a Linux system starts up. When I first started learning I just pressed the power button and waited. Now I want to understand the steps happening behind the screen.

Understanding the startup process is important. If a system fails to start you need to know which step went wrong to fix it. Here is what happens when you turn on a Linux machine.

The Startup Steps

The process follows a specific order. Each step prepares the system for the next one.

1. BIOS and UEFI

When you turn on the computer the first thing that runs is the BIOS or UEFI. This is small software stored on your motherboard. It checks your hardware like your RAM and keyboard to make sure everything is working. This check is called a POST.

2. The Bootloader

Once the hardware is ready the BIOS looks for a bootloader. In Linux the most common one is called GRUB. The job of the bootloader is to load the Linux Kernel into the memory of the computer. There is a funny story linked to the GRUB, this is why I love to document my entire learning process, because even before I continued with the learning process into chapter 4, I literally forgot the password to the laptop I installed the Linux on! I had to do a quick google search on how to reset your ubuntu passcode at the welcome screen, and it was actually a smooth processs really, All I had to do was to hard restart my machine thrice, and it did take me to the GRUB bootloader, so I really had a happy moment when I saw that in the online course :)

3. The Linux Kernel

The kernel is the heart of the operating system. It manages the hardware and the memory. It also starts the very first process on the system.

4. Init and Systemd

The kernel starts a process called init. On most modern Linux systems this is now called systemd. This is the mother of all processes. It has a process ID of 1. Its job is to start all the other services you need like your network or your desktop interface.

Kernel Space and User Space

The system is divided into two parts.

Kernel Space is where the kernel runs. It has full access to the hardware.

User Space is where your applications like a browser or a terminal run.

This division keeps the system safe. If an app in the user space crashes it should not take down the whole kernel.

A Useful Command

One way to see what happened during your startup is using the dmesg command.

dmesg | less

I will explain this command thoroughly.

dmesg stands for display message. It shows the messages from the kernel buffer. These are logs that tell you exactly what the kernel did while the system was starting.

The pipe symbol takes the output of the first command and sends it to the second command.

less is a tool that lets you scroll through a long list of text one page at a time.

Using this command is a great way to see how the kernel interacts with your hardware.

My Progress

Learning these basics helps me move away from just following tutorials. Instead of guessing why a system is slow or not starting I can now look at the logs and understand the steps.I am enjoying documenting this path as I learn how systems work under the hood.

And for my flash card buddies, I have updated Flashy, it has flash cards for this chapter of the course, in case you want to revise :)

I Stopped Trying to Learn Every DevOps Tool: And Started Building a Platform Instead

Maame Afua A. P. Fordjour — Wed, 11 Feb 2026 05:17:40 +0000

The DevOps Hero Burnout is Real

Let's be real for a second. being a student and juggling school work with external studies is the TOUGEST thing ever, my first few months in the DevOps world felt like a total nightmare. Every roadmap I looked at was just a giant wall of logos: Docker, Kubernetes, Terraform, Ansible, Jenkins, ArgoCD, Prometheus, Grafana... the list literally never ends.

The advice was always the same: "You need to know how everything works under the hood." But here is the reality: system complexity has officially outpaced what one person can actually coordinate. Trying to be a DevOps Hero who masters every single tool is a losing battle that leads straight to burnout before you even graduate. I was spending 80% of my time fighting with messy YAML files and only 20% actually building cool things.

So, I decided to stop. I stopped trying to learn every single tool, and I started building a Platform for myself instead.

The Shift: From Tool Fatigue to Golden Paths

In the industry right now, we are seeing a massive shift. By 2026, it is predicted that 80% of software engineering organizations will have dedicated platform teams. Why? Because the "You build it, you run it" culture, while great in theory, usually breaks down when things get big.

It creates a Cognitive Load that is simply too heavy. Senior engineers end up becoming "human glue," spending all their time helping others provision basic infrastructure instead of actually innovating.

Platform Engineering solves this by creating Internal Developer Platforms (IDPs). The goal isn't to take away a developer's power, but to give them Golden Paths: pre-defined, best-practice workflows that allow them to ship code without needing to be an infrastructure expert.

What I Built: My Personal IDP (TutorCLI)

Instead of manually configuring every single deployment, I built a tool called TutorCLI. It is my own personal version of an Internal Developer Platform.

Instead of me having to remember the exact flags for a complex tar backup or a docker network command, my platform handles the complexity for me. It provides:

Abstraction: It hides the low-level infrastructure details behind a simple interface.

Self-Service: I can provision what I need without waiting for my own "mental" approval or re-reading documentation for the 10th time.

Safety Guardrails: It audits my commands for common student mistakes, like the danger of a destructive rm -rf, before they even execute.

Building this taught me more about DevOps than any 10-hour tutorial ever could. I wasn't just using tools; I was architecting a system that made those tools invisible.

Why Platform-as-a-Product is the Future

The secret to viral growth in 2026 isn't knowing the most tools. It is about understanding Developer Experience (DevEx).

High-maturity platform teams report a 40-50% reduction in cognitive load for their developers. This allows teams to move from environment provisioning taking days to taking just a few hours. We are moving away from "enablement-by-heroics" and toward "enablement-by-design."

For students, this is a superpower. If you can show an employer that you don't just know how to use Kubernetes, but you know how to build a platform that makes Kubernetes easy for others, you are ahead of 90% of the applicant pool.

3 Simple Steps to Start Your Own Platform Journey

If you are a student feeling overwhelmed by the toolchain, just stop. Do this instead:

Identify your "Toil": What is the one command or configuration you have to look up every single time?

Build a Wrapper: Write a script or a simple CLI, like my TutorCLI, that automates that specific Golden Path.

Standardize Your Patterns: Stop reinventing the wheel for every project. Create a template that encodes your best practices for security and deployment.

Final Thoughts

The era of the Generalist Hero is ending. We are moving into the era of the Platform Engineer. Don't just learn the tools: build the stage they perform on.

GitHub Copilot CLI Challenge: 'The Linux Compass'

Maame Afua A. P. Fordjour — Tue, 27 Jan 2026 07:21:14 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built The Linux Compass, a terminal-based utility designed to bridge the gap between AI discovery and permanent technical knowledge.

As a Computer Science student , I am currently documenting my journey into infrastructure through a Linux/DevOps learning series. I noticed a recurring problem: I would use GitHub Copilot CLI to find a command, use it once, and then forget it. This "knowledge decay" is a major hurdle for students. I created a basic website for an web based app called 'Flashy' (Flashcard learning style because I am a slow learner and suffering with extreme ADHD), but that was not enough either, this challenge pushed me to create something that will be beneficial to me, and other students out there to solve that problem whiles in the terminal.

The Linux Compass wraps the GitHub Copilot Agent in a Python workflow that forces a "Learning Loop." It captures the user's goal, assists in finding the command, triggers an educational breakdown (the "why"), and then automatically synchronizes the session into a persistent Markdown study log (LINUX_STUDY_LOG.md).

Demo

GitHub Repository: Linux-compass

How it Works:
(Go through the ReadMe in the Github repo to get started!)

Below are screenshots of how it works:

1)Initiating a Query The tool greets the user and consults the Copilot Agent for the specific Linux task.

2) The Educational Breakdown The Compass doesn't just provide an answer; it enforces understanding by calling the explain agent automatically.

3) Successful Synchronization The session concludes with a success message once the data is safely logged.

4)The Persistent Study Log By opening LINUX_STUDY_LOG.md, we see the automated entry: timestamp, learning goal, and verified command. This creates a structured, searchable history of my technical growth.

My Experience with GitHub Copilot CLI

My journey with the GitHub Copilot CLI was a rollercoaster of technical troubleshooting that ultimately made me a better developer.

The Struggles:

The biggest challenge was dealing with the 2026 Agentic Update of the GitHub CLI. Early in development, I faced a "Version Conflict" where the CLI refused to recognize simple prompts. I kept getting the error: error: Invalid command format.

I had to dive deep into the CLI documentation to discover the new Interactive Payload Pattern. I learned that the 0.0.395 version of the extension required the suggestcommand and the -p prompt to be passed as a single, nested string within the -i (interactive) flag.

The Breakthrough:

Once I understood how Python's subprocess module needed to "hand over" terminal control to the Copilot agent, everything clicked. I also navigated Windows-specific hurdles, such as migrating my project from the restricted System32 directory to a trusted user space and upgrading to PowerShell Core (pwsh) to support the modern Copilot features.

The Impact:

GitHub Copilot CLI turned the terminal from a "scary black box" into an interactive tutor. Instead of just giving me a command, the explain feature allowed me to build a tool that teaches me. For a student aiming for a career in DevOps, this isn't just a shortcut it's a productivity multiplier that ensures I am learning efficiently while I build.