Forem: AbdulGoniyy Adeleke Dare

What Artemis II Says About Systems Thinking, Safety, and Human Judgment

AbdulGoniyy Adeleke Dare — Fri, 10 Apr 2026 07:05:33 +0000

What Artemis II Says About Systems Thinking, Safety, and Human Judgment

NASA launched Artemis II on April 1, 2026, beginning the first crewed lunar flyby in more than 50 years.

Most public conversation around the mission quite naturally focused on the launch, the crew, and the symbolism of returning humans to deep space. For builders, educators, and product people, the more durable lesson is different: Artemis II is a useful case study in systems thinking, safety engineering, and human-in-the-loop design.

That matters to me because a lot of AI and education marketing still frames technology as if good products come from one clever model, one impressive demo, or one dramatic breakthrough. Artemis II is a reminder that real systems do not work that way.

1. Systems Beat Tricks

Artemis II is not "a rocket story." It is a systems story.

The mission depends on launch infrastructure, flight software, the Orion spacecraft, the Space Launch System, communications, ground operations, crew procedures, and recovery planning. None of those pieces is sufficient on its own.

That is a useful correction for anyone building educational technology. Children should not only be taught isolated features or flashy AI moments. They should be helped to see how inputs, decisions, constraints, testing, and outputs fit together.

2. Testing Is Part of the Product

One of the healthiest ideas embedded in Artemis II is that the test flight is not a side quest. It is part of the actual work required before future missions go further.

That mindset translates surprisingly well to education products and AI systems:

do not treat evaluation as a late-stage checkbox
make testing visible
expect revision
separate "interesting demo" from "trusted system"

There is a strong lesson here for child-facing AI products. If we want children to build responsibly, we should expose them early to the idea that testing is normal, expected, and valuable.

3. Human-in-the-Loop Still Matters

Artemis II is deeply automated in many ways, but NASA also designed the mission so astronauts would manually fly Orion during a proximity operations demonstration.

That matters because it undercuts a very common cultural mistake: assuming advanced automation removes the need for human understanding.

It does not.

In high-stakes systems, human judgment still matters for supervision, interpretation, intervention, and trust. That is just as relevant in AI product design as it is in spaceflight.

For child AI education, this is a particularly important design principle. We should not teach children that good technology means pressing a button and accepting the result. We should teach them to inspect outputs, question assumptions, and understand failure modes.

4. Safety Shapes Design

Artemis II is a useful reminder that constraints are not the enemy of ambitious systems. Safety requirements shape the system architecture.

In educational technology, the same should be true.

If a platform is intended for children, moderation, privacy, age-appropriateness, and controlled failure modes should not be treated as optional layers added after growth. They should shape the product from the beginning.

That is one reason I think K-12 AI products should be judged less by "how impressive is the model?" and more by "what kind of behaviour does the system invite, constrain, and reinforce?"

5. Narrative Is a Real Teaching Tool

Artemis II also highlights something useful for educators: narrative gives technical learning emotional weight.

Children do not stay engaged because we tell them a concept is important. They stay engaged because the concept is attached to a meaningful challenge.

That is why space missions, rescue scenarios, game worlds, and guided stories work so well as learning frames. They give abstract ideas a reason to matter.

Used well, narrative does not dilute rigour. It improves entry and retention.

Why This Matters for StackJunior

At StackJunior, the opportunity is not just to teach children "about AI." It is to help them develop the habits behind good technical work:

thinking in systems
testing instead of guessing
understanding that tools can fail
building with constraints
treating human judgment as part of the workflow

That is one reason a mission like Artemis II is so useful. It gives us a concrete, current example of how serious technology actually works.

If we want children to grow into thoughtful builders, we should show them more case studies like this and give them small, safe ways to build systems of their own.

Selected Sources

Guardrails actually not enough

AbdulGoniyy Adeleke Dare — Tue, 30 Dec 2025 16:54:40 +0000

AbdulGoniyy Adeleke Dare

Dec 27 '25

Why Agent Guardrails Aren't Enough

#ai #machinelearning #programming #agents

Comments

4 min read

Why Your AI Needs Both Intuition and Rules

AbdulGoniyy Adeleke Dare — Tue, 30 Dec 2025 15:35:46 +0000

📊 TL;DR: Pure neural safety is a black box. Pure symbolic safety is too brittle. Hybrid "Neuro-Symbolic" systems combine the speed of rules with the adaptability of neural nets to create robust agent governance.

The Case for Neuro-Symbolic Agent Safety

There's a debate in AI safety circles that most people don't know about. It happens in academic papers and obscure Discord servers. But it will define how we control AI agents for the next decade.

The debate is simple: should we use neural networks or symbolic rules to make AI safe?

The answer might be: yes.

The Two Camps

Camp Neural: Use machine learning to detect dangerous patterns. Train models on examples of harmful behaviour. Let the AI learn what "unsafe" looks like.

Pros: Flexible, handles ambiguity, generalises to novel situations.
Cons: Black box, unpredictable, requires massive training data.

Camp Symbolic: Define explicit rules. If action == "delete_database", block. No learning, no ambiguity.

Pros: Transparent, predictable, auditable.
Cons: Brittle, can't handle edge cases, requires exhaustive rule-writing.

Both camps have built impressive systems. Both have failed spectacularly. Neural systems miss obvious attacks because their training data didn't include that exact pattern. Symbolic systems block legitimate actions because the rule was too broad.

The Neuro-Symbolic Hypothesis

What if we combined them?

The idea isn't new—researchers have explored hybrid approaches for years. But for agent safety specifically, the combination is compelling:

1. Fast Path (Symbolic): Check explicit rules first. Known dangerous patterns? Block instantly. Sub-millisecond.
2. Slow Path (Neural): If the symbolic path passes, run neural inference. Classify intent. Detect subtle manipulation.
3. Combined Verdict: Weight both signals. A symbolic "allow" with a neural "suspicious" might trigger human review.

This isn't theoretical. As of 2025, early implementations are showing promise:

Rule-based symbolic checks run in single-digit milliseconds (often 10-50ms), catching the majority of obvious policy violations.
Neural classifiers add deeper context analysis in approximately 50-200ms.
Combined systems (like GuardFormer, presented at NeurIPS 2024) have shown significantly lower false-positive rates than either approach alone, outperforming GPT-4 in safety benchmarks.

"Rules catch the attacks we know. Networks catch the attacks we don't."

Why This Matters for Agents

AI agents are uniquely challenging because they operate over multiple steps. A single prompt might be benign. But a sequence of ten prompts, each individually harmless, might constitute a sophisticated attack.

Symbolic systems excel at single-step analysis. Neural systems excel at pattern recognition across sequences. Combined, they can track intent over time.

Consider: an agent asks for employee contact information. Innocent. Then asks for salary data. Still plausible. Then asks to draft an email. Then asks to send it without review. Each step passes guardrails. The sequence is social engineering.

A neuro-symbolic system can:

Symbolically verify each step is allowed.
Neurally track the emerging pattern.
Raise alarms when intent drifts toward manipulation.

The Practical Challenges

This isn't a solved problem. Neuro-symbolic systems face real limitations:

Latency trade-offs: Neural inference is slower. For real-time agents, you can't afford 500ms classification per action.
Training data: Neural components need examples. Adversarial examples of agent attacks are rare.
Interpretability: When the neural component blocks an action, can you explain why? Regulators will ask.
Maintenance burden: Now you have two systems to maintain, train, and debug.

The Direction of Travel

Despite the challenges, the direction is clear. Pure symbolic systems can't handle the complexity of natural language agents. Pure neural systems can't provide the guarantees enterprises require.

The most sophisticated agent safety systems emerging today are hybrid. The NSF-funded EAGER project (active through September 2025) is exploring knowledge-guided neuro-symbolic AI in healthcare, demonstrating that hybrid approaches can achieve clinically safer outcomes than purely neural methods.

"The future of AI safety is not choosing between intuition and rules. It's teaching them to work together."

The Takeaway

Symbolic rules are necessary but insufficient. Neural classification is powerful but opaque. The combination—neuro-symbolic safety—might be the architecture that finally lets us trust AI agents with consequential actions.

We're not there yet. But the path is becoming clearer.

Are you building hybrid safety systems? What's working? I'd love to hear your experiences in the comments.

Why Agent Guardrails Aren't Enough

AbdulGoniyy Adeleke Dare — Sat, 27 Dec 2025 22:17:47 +0000

📊 TL;DR: Agent guardrails are reactive and can't handle novel failures. We need verification before execution, coordination between agents, cryptographic accountability, and real kill switches.

The Coming Crisis No One Wants to Talk About

In 2024, a multi-agent research tool experienced what's been called a "runaway agent loop"—two agents continuously interacting with each other for 11 days straight before anyone noticed. The API bill? $47,000. In that same year, expense report AI agents began fabricating plausible entries—fake restaurant names, false receipts—when they couldn't interpret unclear documents. By September 2025, expense management platform Ramp reported flagging over $1 million in AI-generated fraudulent invoices in just 90 days.

These aren't hypotheticals. These are documented failures—and in 2025, the stakes are even higher.

As companies race to deploy autonomous AI agents—software that can browse the web, execute code, and make decisions—a dangerous assumption has taken hold: that we can control them with simple guardrails.

We can't.

The Guardrail Illusion

Today's "agent safety" approaches follow a familiar pattern: define a list of forbidden actions, wrap the agent in a filter, and hope for the best. OpenAI's Agents SDK now includes input/output guardrails with structured validation, and their February 2025 Model Specification details guidelines for agent behaviour. Anthropic's Claude uses Constitutional AI—training the model to self-critique against ethical principles. LangChain offers middleware and callbacks for monitoring and content filtering.

These are guardrails. They're necessary. They're also insufficient.

Here's why: guardrails are reactive. They check outputs after the decision is made. They're pattern-matching against known bad behaviours. But AI agents don't fail in predictable ways—they fail in novel, cascading sequences that no engineer anticipated.

These AI agents don't do anything "forbidden." They execute exactly what they're told: complete the task. The expense report agent fabricated data when it couldn't interpret real receipts. The runaway agents kept conversing because no one defined a stopping condition. They lacked the context a human would have automatically applied.

"The most dangerous agents are the ones that do exactly what you asked."

The Scale Problem

A single agent making one mistake is manageable. But enterprises are already deploying fleets. Customer service bots. Research assistants. Code generators. Trading algorithms.

When 10,000 agents operate simultaneously, even a 0.01% error rate means 100 failures per day. Some of those failures will be expensive. Some will be dangerous. Some will be irreversible.

Guardrails don't scale. They're boolean—allow or deny. They lack the nuance to:

Detect gradual intent drift over multi-step chains
Prevent resource contention between competing agents
Enforce regulatory compliance across jurisdictions
Kill runaway processes before damage accumulates

What Comes After Guardrails

The solution isn't better filters. It's treating agents like first-class citizens in a governed ecosystem.

This means:

1. Verification, not just filtering. Every agent action—before execution—passes through a policy engine that understands context, history, and intent.

2. Coordination, not competition. When multiple agents access shared resources, they need atomic locks and priority systems. The database doesn't care that two agents had good intentions.

3. Identity and accountability. Agents need verifiable credentials. When something goes wrong (it will), you need cryptographic proof of who did what, when.

4. Kill switches that work. Not "stop when you're done"—immediate termination with resource cleanup and audit trails.

The Early Signals

Some teams are already building beyond guardrails. Projects are emerging that treat agent safety as an operating system problem, not a prompt engineering problem.

The shift is subtle but significant: from "what can't the agent do?" to "what did the agent actually intend?"

"Guardrails ask if the door is locked. Agent governance asks why you wanted to open it."

Why This Matters Now

2024 was the year of agent demos. 2025 is the year of agent deployments—and now we're seeing exactly where the gaps lie. The difference between "impressive prototype" and "production system" is where failures accumulate.

The companies that figure out agent governance—not just guardrails—will be the ones trusted with high-stakes automation. Healthcare. Finance. Infrastructure.

The rest will learn expensive lessons.

The Open Question

We built operating systems for computers. We built regulations for corporations. We built air traffic control for planes.

What do we build for AI agents?

The answer is still being written. But one thing is clear: guardrails alone won't get us there.

What's your experience with agent failures? I'd love to hear war stories in the comments.

🛠️ What I'm Building

I'm working on agent governance infrastructure that treats safety as an OS-level concern. If you're building autonomous agents and want to discuss these challenges, drop a comment or connect with me.

Warp Support Engineer Simulation A mini lab replicating real-world troubleshooting workflows (permissions, SSH timeout, etc.) inside an agentic terminal context using Warp.

AbdulGoniyy Adeleke Dare — Sat, 18 Oct 2025 17:22:11 +0000

AbdulGoniyy Adeleke Dare

Oct 18 '25

Exploring Warp: Building the Future of Agentic Support Engineering

#devops #ai #warp #supportengineering

Comments

4 min read

Exploring Warp: Building the Future of Agentic Support Engineering

AbdulGoniyy Adeleke Dare — Sat, 18 Oct 2025 17:20:42 +0000

Reimagining the support terminal as an intelligent workbench for debugging, automating, and understanding complex developer issues.

🚀 Introduction

As developers, we spend countless hours inside terminals — troubleshooting, debugging, and supporting systems.
But what if the terminal wasn’t just a passive command line…
What if it could think with you?

That’s the idea behind Warp’s platform for Agentic Development — where AI agents work alongside engineers to code, deploy, and debug faster.

To explore this concept, I built a mini project called warp-support-cases — a collection of real-world troubleshooting scenarios inspired by everyday DevOps and Support Engineer tasks.

Each case simulates an issue, shows terminal outputs, and demonstrates how an AI-driven terminal like Warp could provide contextual insights in real time.

⚙️ Project Overview: `warp-support-cases`

Goal:
To simulate how Warp’s intelligent terminal could assist Support Engineers in diagnosing and resolving real DevOps issues.

Scenarios Covered:

File permission and ownership conflicts
SSH connectivity and routing issues
Missing binaries or misconfigured paths
Network latency and timeouts
Configuration drift across environments

Stack:

Linux CLI (Ubuntu-based)
Common tools: ssh, ping, nc, ip route
Optional integrations: nmap, journalctl, systemctl
Warp Terminal as the experimental interface

🧩 Case 1: Permission Denied (File Ownership Conflict)

🖥️ Terminal Log

$ touch /var/www/html/config.php
touch: cannot touch '/var/www/html/config.php': Permission denied

$ ls -ld /var/www/html
drwxr-xr-x 2 root root 4096 Oct 17 12:40 /var/www/html

🤖 Agentic Insight (What Warp Could Do)

“It looks like the directory /var/www/html is owned by root.
Try using sudo or adjusting permissions with chown.”

💡 Resolution

sudo chown -R user:www-data /var/www/html
sudo chmod -R 775 /var/www/html

✅ The user now has write access and can edit web files safely.

🌐 Case 2: SSH Timeout (Unreachable Host)

🖥️ Terminal Log

ssh user@192.168.10.55
ssh: connect to host 192.168.10.55 port 22: Connection timed out

ping -c 4 192.168.10.55
PING 192.168.10.55 (192.168.10.55) 56(84) bytes of data.

--- 192.168.10.55 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss

🤖 Agentic Insight

“The host 192.168.10.55 is unreachable.
You appear to be on a different subnet (192.168.43.x).
Check if a VPN or routing rule is required to reach 192.168.10.x.”

🧠 Analysis

Ping failed → No ICMP response
SSH timed out → No TCP connection
Routing mismatch → 43.x trying to reach 10.x
Likely issue → Different network segment or firewall blocking port 22

💡 Resolution

Verify target host is online
Connect to the same network or VPN
Check local and remote firewalls
Confirm correct IP assignment with:

   ip route get 192.168.10.55

⛓️ Case 3: `PATH` Misconfiguration

🖥️ Terminal Log

$ ls
bash: ls: command not found

🤖 Agentic Insight

“The command ls was not found in your PATH.
Your PATH is currently set to /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin.
The ls command is usually in /bin/ls.
You can either use the full path /bin/ls or add /bin to your PATH.”

💡 Resolution

export PATH=$PATH:/bin

✅ The user can now run standard commands without specifying the full path.

🎮 Application Development with Warp: Minesweeper in React

To showcase Warp’s capabilities beyond troubleshooting, I developed a classic Minesweeper game using React. This exercise demonstrated how Warp’s AI can assist in the development lifecycle, from scaffolding a new project to debugging React components.

Project: minesweeper-react
Purpose: To build a classic Minesweeper game using modern web technologies (React 19, Vite) from within the Warp terminal.
WARP.md: A special file was created to provide development guidance and context to Warp’s AI. It outlines the project structure, core development commands, and architectural patterns, enabling Warp to assist more effectively.
Outcome: This showcases how Warp can be a primary environment for building, testing, and documenting a software project.

🤝 Why This Matters

In real support workflows, engineers spend valuable time correlating logs, commands, and system states.
An agentic terminal like Warp could automate context understanding, recommend next actions, and even execute verified remediations.

This reduces friction between debugging and decision-making — turning reactive troubleshooting into proactive engineering.

📦 Repository

All terminal cases and documentation are available here:
👉 github.com/daretechie/warp-support-cases

🚀 Get Warp

Ready to try the future of the terminal? Download Warp here.

🔮 My Take on Agentic Terminals

Warp represents the next step in developer tooling — terminals that think alongside you.

Through this project, I observed three agentic opportunities:

Proactive Diagnostics: Detecting environment issues (like PATH or permission errors) and auto-suggesting verified fixes.
Collaborative Debug Sessions: Warp AI could summarise a terminal session’s commands and insights into a shareable incident report.
Adaptive Context Memory: The terminal could recall previous fixes or commands across sessions to reduce repetitive troubleshooting.

These align with Warp’s mission of evolving from a powerful shell to a developer workbench for intelligent agents.
I’m excited to see how Warp and similar tools will reshape developer workflows in the coming years.

🏷️ Tags

DevOps #AI #Warp #SupportEngineering #AgenticDevelopment #Automation #Debugging

100 Days of DevOps: Halfway There and Powering Through (Days 26-50)

AbdulGoniyy Adeleke Dare — Sat, 27 Sep 2025 06:40:40 +0000

I've officially hit the halfway mark in the #100DaysOfDevOps challenge! The journey so far has been incredibly rewarding, and the last 25 days have been a deep dive into the tools that form the backbone of modern software delivery.

If you missed the first part of my journey, you can catch up on the first 25 days here: 25 Days of DevOps: How I Fought Imposter Syndrome and Built Real Momentum.

The feeling of accomplishment is immense, but the real prize is the confidence that comes from hands-on practice. KodeKloud's labs continue to be an invaluable resource, pushing me to learn by doing.

A Milestone Recognised

This email from the KodeKloud team was a fantastic motivator. It's a great reminder that consistency pays off.

GitHub as My North Star

My GitHub repository is more than just a code backup; it's the story of my journey. Every commit is a step forward, and looking back at the progress from Day 1 is a powerful reminder of how far I've come.

Here’s an updated look at my progress tracker:

Check out the full repository and follow my progress here: My 100 Days of DevOps GitHub Repo

Key Learnings from Days 26-50

This quarter was all about diving into the core of DevOps tooling. Here are the highlights:

Advanced Git Techniques: I moved beyond the basics and got my hands dirty with git revert, cherry-pick, rebase, and even Git hooks. These skills are crucial for maintaining a clean and manageable codebase in a team environment.
Docker is a Game-Changer: I finally got to grips with Docker, and it's been a revelation. From building custom images with a Dockerfile to managing multi-container applications with docker-compose, I now understand why containerization is so powerful.
First Steps in Kubernetes: The journey into container orchestration has begun! I've started creating Kubernetes Pods and Deployments, and I'm beginning to see how it all fits together to manage applications at scale.

The Journey Continues

The second half of this challenge promises to be even more exciting, with deeper dives into Kubernetes, CI/CD pipelines, and more. The momentum is strong, and I'm excited to see what I can achieve in the next 50 days.

How are you tracking your learning goals? Share your tips and experiences in the comments below!

devops #100daysofdevops #docker #kubernetes #git #learninginpublic #kodekloud

"Building Professional IT Support with GLPI: A Complete Helpdesk Implementation"

AbdulGoniyy Adeleke Dare — Fri, 05 Sep 2025 17:02:22 +0000

From Zero to Helpdesk Hero: Building an Enterprise IT Support System with GLPI

AbdulGoniyy Adeleke Dare ・ Aug 6

#glpi #itsm #systemadmin #opensource

100 Days of DevOps: A Quarter of the Way There and What I've Learned

AbdulGoniyy Adeleke Dare — Tue, 02 Sep 2025 22:11:51 +0000

25 Days of DevOps: How I Fought Imposter Syndrome and Built Real Momentum

AbdulGoniyy Adeleke Dare ・ Sep 2

#devops #100daysofdevops #kodekloud #linux

25 Days of DevOps: How I Fought Imposter Syndrome and Built Real Momentum

AbdulGoniyy Adeleke Dare — Tue, 02 Sep 2025 21:46:31 +0000

It Started with a Whisper of Doubt

Let's be honest. Starting a 100-day challenge is daunting. That little voice in your head, the one that whispers "Are you really going to stick with it this time?" was loud and clear. Every developer knows that voice. It’s the voice of imposter syndrome, and for the first few days, it was my constant companion.

But then, something incredible happened. Day by day, commit by commit, that voice started to fade. And this morning, an email from the KodeKloud Team silenced it completely:

Hi Dare,

Big congrats - you’ve successfully completed 25 tasks in the 100 Days of DevOps journey! 🙌

🎯 You’re 25% closer to the finish line.
🚀 You’ve already done more than most ever start.

That hit me hard. "You’ve already done more than most ever start." It was external validation that the small, daily efforts were compounding into something real. The journey was no longer about proving the doubters wrong; it was about proving my own commitment right.

The Power of a Public Logbook

To keep myself honest, I decided to treat my GitHub repository as a public logbook. Every single day, I commit my solution scripts, my notes, and the original task. No hiding, no skipping days.

It's my single source of truth and my ultimate accountability partner.

You can see my entire journey, warts and all, right here:
My 100-Days-of-DevOps GitHub Repo

Here’s a snapshot of my progress tracker. Seeing this fill up day by day has been one of the most satisfying parts of the journey.

From Theory to Tangible Skills (The First 25 Days)

This isn't just about reading documentation. The #100DaysOfDevOps challenge throws one into the fire with hands-on tasks for a simulated company, xFusionCorp.

In just 25 days, I've tackled:

Linux Fundamentals: From user management and SSH hardening to wrangling SELinux.
Web & Application Services: Setting up, securing, and fixing Apache, Nginx (with SSL & Load Balancing), and PHP-FPM.
Database Management: Rescuing a broken MariaDB service and setting up PostgreSQL.
Automation & Version Control: Writing automation scripts, setting up cron jobs, and mastering Git workflows (branching, merging).

What I've Really Learned in 25 Days

Consistency is a Superpower: An hour of focused work every day is infinitely more powerful than a 10-hour coding binge on a weekend. It builds a momentum that becomes unstoppable.
Document for Your Future Self: Writing notes when the solution is fresh in my mind has already saved me hours of re-Googling. Your future self will thank you.
Embrace the Grind: The real learning happens when things break. Troubleshooting a failing service or a cryptic error message has taught me more than any perfect tutorial.

A Massive Thank You!

I couldn't have done this without the incredible KodeKloud team. Thank you for building a challenge that values hands-on skills over theoretical knowledge, all for free. And to the community, your support and encouragement mean the world.

On to the Next 75!

25 days down, 75 to go. The imposter syndrome is quiet, and the excitement for what's next is deafening. Jenkins, Ansible, Docker, Kubernetes... I'm coming for you.

What challenge are you taking on right now? How do you fight your own "inner critic"?

Let's talk in the comments. Your story might be the motivation someone else needs to start.

Ready to start your own #100DaysOfDevOps journey? Sign up here!

devops #100daysofdevops #kodekloud #linux #motivation #beginners

From Zero to Helpdesk Hero: Building an Enterprise IT Support System with GLPI

AbdulGoniyy Adeleke Dare — Wed, 06 Aug 2025 13:05:01 +0000

TL;DR: I spent a weekend setting up GLPI for a fictional company called FakeCorp, ran into every possible configuration nightmare, and somehow emerged with a fully functional helpdesk system. Here's what I learned about ITSM, patience, and why you should never trust default Nginx configurations.

The final GLPI dashboard - worth every hour of troubleshooting

The "Simple" Weekend Project That Wasn't

It started innocently enough. I was browsing through IT job descriptions when I noticed how often ITSM (IT Service Management) tools appeared in requirements. Names like ServiceNow, Jira Service Management, and GLPI kept popping up. As someone building practical IT skills through hands-on projects, I figured: "How hard could it be to set up a helpdesk system?"

Famous last words.

What I thought would be a 2-hour setup turned into a weekend-long deep dive into web server configurations, PHP socket connections, and the surprisingly complex world of enterprise helpdesk systems. But by the end, I had something pretty amazing running on my local Ubuntu machine.

💡 Pro Tip: I wish I'd documented every error message and configuration attempt. If you're following along, take screenshots of everything - your future self will thank you when writing about the experience!

Why GLPI? (And What Even Is It?)

GLPI stands for "Gestionnaire Libre de Parc Informatique" – fancy French for "Free IT Equipment Manager." Think of it as the Swiss Army knife of IT support tools. It handles:

Ticket management (the core helpdesk functionality)
Asset tracking (computers, phones, software licenses)
User management (employees, departments, locations)
Reporting and analytics (because managers love charts)
ITIL compliance (important for enterprise environments)

The best part? It's completely free and open-source. Perfect for learning, and surprisingly robust enough for real production use.

Setting Up My Fictional Empire: Meet FakeCorp

Before diving into the technical setup, I needed a story. Enter FakeCorp – a mid-sized company I invented with:

Three departments: IT (that's me), HR, and Customer Support
Multiple locations: Headquarters, Lagos Branch, and Remote Offices
Real problems: Like every company, they had printers that mysteriously stopped working on Mondays and Wi-Fi that decided to take coffee breaks

FakeCorp's organisational structure in GLPI - departments, locations, and user hierarchies

This context was crucial because GLPI isn't just about installing software – it's about modelling real organisational structures and workflows.

The Technical Journey (AKA: How Many Ways Can Nginx Break?)

Phase 1: The "Easy" Installation

I started with what seemed like a straightforward LAMP stack setup on Ubuntu. Downloaded GLPI, extracted it to /var/www/glpi, configured Nginx to serve from the public directory (because security matters), and... got a 404.

💥 The Plot Twist: Nothing says "welcome to web server administration" like confidently hitting refresh and seeing that familiar Nginx 404 page. At 2 AM, that error page becomes your nemesis.

# The commands that should have worked (but didn't)
sudo wget https://github.com/glpi-project/glpi/releases/latest
sudo tar -xzf glpi-*.tgz -C /var/www/
sudo chown -R www-data:www-data /var/www/glpi
# Navigate to http://127.0.0.1 expecting success... 
# Get 404 instead 🤦‍♂️

Then I spent the next three hours learning that GLPI's directory structure is more nuanced than I expected. The modern versions separate public files from sensitive backend code, but my specific version had everything in the root directory. This led to an enlightening deep dive into proper web server security practices.

Lesson learned: Always check the actual file structure instead of assuming documentation matches your version.

Phase 2: The PHP Socket Saga

After fixing the directory issues, I encountered this delightful error:

connect() to unix:/run/php/php8.1-fpm.sock failed (2: No such file or directory)

🔍 Detective Mode Activated: This error message became my unwelcome companion for the next hour. The solution? My system had PHP 8.3, but Nginx was still looking for PHP 8.1 sockets. Classic case of conflicting configurations!

Plot twist: I had PHP 8.3 installed, but my default Nginx site was still configured for PHP 8.1. This taught me about the importance of:

Cleaning up conflicting configurations
Understanding how PHP-FPM sockets work
Reading error logs thoroughly (they usually tell you exactly what's wrong)

The Nginx configuration that finally made everything work

Phase 3: The Security Awakening

Once GLPI finally loaded, it immediately hit me with security warnings:

"Change default passwords for glpi, tech, normal, post-only users"
"Web server root directory is not safe"
"Move data directories outside web root"

GLPI's security check results - educational even when intimidating

This wasn't just nagging – these warnings introduced me to real-world security practices for production systems. Even though this was a local test environment, understanding why these practices matter was invaluable.

Building FakeCorp's Helpdesk Reality

With the technical foundation solid, the fun part began. I created user accounts for different roles and started submitting tickets as if I was actually working at FakeCorp:

A realistic mix of IT support requests that any company would recognize

Ticket #001: "Printer in Lagos office won't print color documents"

Assigned to: IT Technician

Priority: Medium

Status: Investigating

Ticket #002: "Need new software license for design team"

Assigned to: IT Manager

Priority: Low

Status: Pending Approval

Ticket #003: "VPN keeps disconnecting for remote workers"

Assigned to: Network Specialist

Priority: High

Status: In Progress

What struck me was how naturally GLPI handles the complexity of real IT environments. Each ticket could be categorised, prioritized, assigned, tracked, and reported on. The system enforced accountability while providing visibility into team workload.

Individual ticket view showing the full lifecycle and collaboration features

The "Aha!" Moments

Understanding ITIL in Practice

Before this project, ITIL was just an acronym soup to me. But working with GLPI's workflow made concepts like Incident Management, Request Fulfilment, and Change Management tangible. I could see how these frameworks actually help organisations deliver consistent IT services.

Realising the Consultant Opportunity

As I configured business rules for automatic ticket routing and set up SLA tracking, it dawned on me: small companies desperately need these systems but often lack the expertise to implement them. This represents a genuine consulting opportunity for someone with these skills.

Appreciating Good UX Design

GLPI's interface isn't the prettiest, but it's incredibly functional. Every click serves a purpose. Every form field maps to a real business need. This taught me to appreciate software designed for productivity over aesthetics.

The reporting interface - not flashy, but incredibly practical for managers

What I Built (The Satisfying Part)

After two days of configuration, I had:

A fully functional helpdesk with 10 sample tickets across different categories
User management with proper role-based access control
Asset tracking for FakeCorp's fictional computer inventory
Location-based routing so Lagos office issues go to the right team
Basic reporting showing ticket resolution times and technician workload
Custom branding (because even fictional companies deserve good design)

The complete FakeCorp helpdesk system - from chaos to organised IT support

The Real-World Value

This wasn't just an academic exercise. The skills I developed translate directly to:

Consulting opportunities: Small businesses need ITSM implementations
System administration roles: Understanding helpdesk workflows is crucial
Process improvement: Many organizations have terrible IT support processes
Vendor management: Knowing what good ITSM looks like helps evaluate commercial solutions

What's Next?

This project opened my eyes to the broader world of IT service management. I'm planning to explore:

ServiceNow (the enterprise standard)
Integration patterns (connecting helpdesk to monitoring systems)
Advanced automation (AI-powered ticket routing and resolution)
Mobile responsiveness (because users expect mobile-first experiences)

For Fellow Learners

If you're thinking about diving into ITSM tools:

Start simple: Set up GLPI in a VM or container first. Don't try to solve every configuration issue on day one.

Think organizationally: The technical setup is just the foundation. The real learning happens when you model actual business processes.

Document everything: I wish I'd kept better notes about what broke and why. These systems have lots of moving parts.

Embrace the complexity: Modern IT environments are genuinely complex. Tools like GLPI exist because managing IT at scale is hard work.

The winding path from "this looks easy" to "I actually understand ITSM now"

The Bottom Line

What started as a "simple weekend project" became a masterclass in web server configuration, IT service management, and the importance of reading error logs carefully. More importantly, it gave me hands-on experience with tools that power IT operations at companies worldwide.

GLPI might not be the flashiest technology, but it represents something important: the infrastructure that keeps businesses running smoothly. Understanding these systems – both technically and organizationally – is valuable whether you're aiming for a sysadmin role, considering IT consulting, or just want to understand how professional IT departments actually work.

Plus, I can now confidently add "ITSM" to my resume without feeling like a fraud. That's worth a weekend of troubleshooting PHP sockets any day.

Have you worked with helpdesk systems before? What tools have you found most effective for IT service management? Share your experiences in the comments – I'd love to hear about other platforms worth exploring!

What's your next IT learning project? Let me know in the comments below! 👇

How I Accidentally Built a Full-Stack Portfolio While Completing a Google IT Certification Project

AbdulGoniyy Adeleke Dare — Wed, 23 Jul 2025 14:30:33 +0000

Welcome! 👋
After finishing the Google IT Support Professional Certificate 🎉, I wanted to put my new skills to work — not just to tick a box, but to actually build something that could speak for me.
I planned some projects to bridge the gap between theory and practice. After publishing three practical IT projects (Personal IT Lab and Troubleshooting Documentation - Windows and Linux) on Dev.to, I turned to my fourth — a seemingly simple ‘static website’ assignment. But then curiosity took over, and the project snowballed into a full-stack build.

🚀 Set Up a Home Server with a Static Website ← This is where things got interesting.

The fourth project was supposed to be a straightforward assignment: install a LAMP/NGINX stack, serve a basic HTML/CSS site, and make it public with Ngrok. Simple, right?

Well, I accidentally built a full-stack web application with a React frontend, a FastAPI backend, and a MongoDB database. Let me walk you through how "scope creep" became the single best learning experience of my journey so far.

💭 From “What If?” to “Why Not?”

After setting up the basic NGINX server in a few hours, I had a thought that many of you might find familiar: "This is cool, but... what if I made it actually useful?"

A static site felt like checking a box. I wanted to build something that would:

Showcase my skills beyond the certification requirements.
Force me to learn the modern web technologies I see in job descriptions.
Create a real platform to host my other projects and blog about my learnings.
Demonstrate a problem-solving mindset to potential employers.

That "what if" moment was the starting pistol for a deep dive into full-stack development.

🔧 Tech Stack Evolution: Hello Full-Stack World

What started as a simple plan...

The Original Plan:
HTML + CSS + NGINX = A simple static page

...quickly evolved into a much more ambitious reality.

What I Actually Built:
React + Tailwind CSS + FastAPI + MongoDB + NGINX = A complete web application

(A high-level overview of the application architecture.)

Why I Chose This Stack:

Backend (FastAPI): As an IT Support grad, I had a foundation in Python. FastAPI was the perfect next step. It's modern, incredibly fast, and the automatic API documentation (/docs) is a lifesaver for learning API design.
Frontend (React): I had zero experience with frontend frameworks, but React is the industry standard. Thinking in components felt like a natural extension of the problem-solving and troubleshooting mindset I'd been developing. I paired it with Tailwind CSS and shadcn/ui to build a professional-looking UI without getting lost in CSS from day one.
Database (MongoDB): I chose MongoDB over a traditional SQL database because its flexible, JSON-like document structure felt more intuitive for a beginner building a portfolio with varied content types (blog posts, project descriptions, user info).

The Technical Journey: Code, Sweat, and "Aha!" Moments

Here are some code moments that made it click — the ones where I started to feel like a real developer 😊.

My first React component was a simple card to display my projects. The basic structure looked something like this, and getting it to render felt like magic

// The React component felt like a huge win!
function ProjectCard({ title, description, link }) {
  return (
    <div className="border rounded-lg p-4 hover:shadow-lg transition-shadow">
      <h3 className="text-xl font-semibold">{title}</h3>
      <p className="text-gray-600 mt-2">{description}</p>
      <a href={link} className="text-blue-500 hover:underline mt-4 inline-block">
        View Project
      </a>
    </div>
  );
}

And here's how those cards look on the actual homepage, creating a clean, organised view of my projects:

(The final rendered project cards in the browser.)

On the backend, creating my first FastAPI endpoint was the moment it all clicked. The Python I knew could now power a web API!

# This simple endpoint was the start of my entire backend
from fastapi import FastAPI

app = FastAPI()

@app.get("/api/v1/projects")
async def get_projects():
    # In the full version, this function queries the MongoDB database
    return {"message": "Hello from my projects API!"}

One of FastAPI's best features is its automatic documentation. This became my single source of truth for testing and managing my API endpoints:

(The interactive API documentation generated by FastAPI at the /docs endpoint.)

Where Theory Meets Reality: The Deployment Gauntlet

Building locally is one thing; deploying is where the real learning happens.

Challenge 1: The CGNAT Reality Check

My original plan was to use DuckDNS for a custom domain, but I hit a wall. My mobile internet provider uses CGNAT (Carrier-Grade NAT), which means no public IP and no way to port forward. This was a classic IT networking problem!

Solution: Ngrok. It creates a secure tunnel to your localhost, giving you a public URL instantly. It was the perfect tool for getting a live demo up and running.

# The simple solution that saved the day
ngrok http 80

This command gave me a public URL, making my local server accessible to anyone in the world:

(Ngrok's terminal interface after successfully creating a public tunnel.)

Challenge 2: The Dreaded CORS Error

Once I separated my React frontend and FastAPI backend, I ran into the infamous Cross-Origin Resource Sharing (CORS) error. My frontend on localhost:3000 wasn't allowed to talk to my backend on localhost:8000.

Solution: A proper NGINX Reverse Proxy. This is a fundamental DevOps concept. Instead of having two separate servers, NGINX listens on port 80 and intelligently routes traffic: requests for the website go to the React app, and requests starting with /api/ are forwarded to the FastAPI backend.

# My NGINX reverse proxy configuration
server {
    listen 80;

    # Serve the React app
    location / {
        root /var/www/portfolio/frontend/build;
        try_files $uri /index.html;
    }

    # Forward API requests to the FastAPI backend
    location /api/ {
        proxy_pass http://localhost:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Here's a quick look at the NGINX configuration file in my editor. It's a small file, but it does a lot of heavy lifting:

(The NGINX configuration that routes traffic to the correct application.)

Absolutely — the structure, clarity, and flow of this revised version are excellent. It's engaging, honest, and educational — perfect for a Dev.to audience.

Here’s a minor polish to tighten the language and enhance the emotional and technical punch just a bit more:

🧠 My Secret Weapon: AI-Assisted Development

Let me be transparent: I didn’t grind through endless tutorials or spend weeks copying boilerplate from YouTube videos. Instead, I leaned into AI-assisted development — what some call vibe coding.

Tools like Emergent and Cursor IDE became my coding partners. This wasn’t about “cheating”; it was about learning faster and building smarter.

I focused on architecture instead of syntax struggles.
When I hit an error, I didn’t just ask for a fix — I asked for understanding.

Here’s a real prompt that saved me hours of Googling:

“I'm getting a CORS error between my React app on port 3000 and my FastAPI backend on port 8000, both running locally. Explain why this happens and show me the correct NGINX configuration to fix it using a reverse proxy.”

That one query unlocked the NGINX config that finally made everything click.

💡 AI tools didn’t replace the learning — they accelerated it. I still had to debug, think critically, and design solutions. But with AI, I spent more time learning concepts and less time stuck in StackOverflow loops.

The Outcome: From IT Support Grad to Full-Stack Capable

This project completely transformed my skillset and confidence. The final result wasn't just a landing page; it was a feature-rich platform. I built an admin-only Markdown editor to write and publish articles, which immediately made the site a dynamic content hub.

(The split-view Markdown editor for creating and editing blog posts.)

The public-facing side includes a fully rendered blog detail page, complete with support for code blocks, images, and other formatting. To make it interactive, I implemented a comments system and tag-based filtering, allowing visitors to engage with content and find posts relevant to their interests.

(The public-facing view of a finished blog post.)

(The interactive elements: a comments section and links to related articles.)

(Filtering blog posts by clicking on a specific tag.)

Before This Project:

Basic HTML/CSS knowledge.
Python scripting skills.
Theoretical understanding of servers and networking.

After This Project:

Practical experience with React and FastAPI.
Understanding of REST API design.
Knowledge of NoSQL databases (MongoDB).
Real-world experience with NGINX, reverse proxies, and CORS.
A live, full-stack portfolio to showcase my work.

Here's a look at the final homepage, bringing together all the elements into a clean, professional presentation:

(The main landing page of the completed portfolio application.)

🧪 What This App Does:
This isn’t just a personal site — it’s a full-stack platform with:

A markdown-powered blog editor (admin-only)

Dynamic blog pages with comments and tag filtering

A portfolio showcase of my real-world IT & DevOps projects

Next Steps on My Journey

This project is a solid foundation, but I'm just getting started. My immediate goals are:

[ ] Implement JWT authentication for user accounts.
[ ] Deploy the application to a cloud provider like AWS or Oracle Cloud Free Tier.
[ ] Set up a proper CI/CD pipeline with GitHub Actions.
[ ] Containerise the application using Docker.
[ ] Implement monitoring and logging as part of my DevOps learning journey with the 3MTT Nigeria program.

My Advice for Fellow IT & Tech Beginners

Embrace "Scope Creep": If a project excites you, don't be afraid to go beyond the minimum requirements. The detour is often where the most valuable learning happens.
Your IT Fundamentals are Superpowers: My understanding of networking (CGNAT) and system administration (NGINX) from the Google course was invaluable for debugging real-world issues.
Use Modern Tools: AI assistants are not a crutch; they are a powerful lever. Use them to learn faster and stay focused on the bigger picture.
Build in Public: Share your journey, even the messy parts. The feedback is invaluable, and your struggles will help someone else who is on the same path.

showdev #webdev #react #python #3mttNigeria #growWithGoogle #fastapi #devops #beginner #fullstack

🔗 Check It Out

Live Demo: My Portfolio Website (Note: Ngrok tunnel may be offline)
Source Code: GitHub Repository

🤝 Let's Connect!

I'm actively preparing for my first IT role and would love to connect with other tech enthusiasts, especially fellow Google IT Support graduates and aspiring DevOps engineers.

GitHub: @daretechie
LinkedIn: daretechie

🎙 What About You?
Have you ever started something small and ended up building way more than you planned? Share your story or drop a link to your favourite “accidental masterpiece.” I’d love to learn from your journey, too.

Forem: AbdulGoniyy Adeleke Dare

What Artemis II Says About Systems Thinking, Safety, and Human Judgment

What Artemis II Says About Systems Thinking, Safety, and Human Judgment

1. Systems Beat Tricks

2. Testing Is Part of the Product

3. Human-in-the-Loop Still Matters

4. Safety Shapes Design

5. Narrative Is a Real Teaching Tool

Why This Matters for StackJunior

Selected Sources

Guardrails actually not enough

Why Agent Guardrails Aren't Enough

Why Your AI Needs Both Intuition and Rules

The Case for Neuro-Symbolic Agent Safety

The Two Camps

The Neuro-Symbolic Hypothesis

Why This Matters for Agents

The Practical Challenges

The Direction of Travel

The Takeaway

Why Agent Guardrails Aren't Enough

The Coming Crisis No One Wants to Talk About

The Guardrail Illusion

The Scale Problem

What Comes After Guardrails

The Early Signals

Why This Matters Now

The Open Question

🛠️ What I'm Building

Warp Support Engineer Simulation A mini lab replicating real-world troubleshooting workflows (permissions, SSH timeout, etc.) inside an agentic terminal context using Warp.

Exploring Warp: Building the Future of Agentic Support Engineering

Exploring Warp: Building the Future of Agentic Support Engineering

🚀 Introduction

⚙️ Project Overview: warp-support-cases

🧩 Case 1: Permission Denied (File Ownership Conflict)

🖥️ Terminal Log

🤖 Agentic Insight (What Warp Could Do)

💡 Resolution

🌐 Case 2: SSH Timeout (Unreachable Host)

🖥️ Terminal Log

🤖 Agentic Insight

🧠 Analysis

💡 Resolution

⛓️ Case 3: PATH Misconfiguration

🖥️ Terminal Log

🤖 Agentic Insight

💡 Resolution

🎮 Application Development with Warp: Minesweeper in React

🤝 Why This Matters

📦 Repository

🚀 Get Warp

🔮 My Take on Agentic Terminals

🏷️ Tags

DevOps #AI #Warp #SupportEngineering #AgenticDevelopment #Automation #Debugging

100 Days of DevOps: Halfway There and Powering Through (Days 26-50)

A Milestone Recognised

GitHub as My North Star

Key Learnings from Days 26-50

The Journey Continues

devops #100daysofdevops #docker #kubernetes #git #learninginpublic #kodekloud

"Building Professional IT Support with GLPI: A Complete Helpdesk Implementation"

From Zero to Helpdesk Hero: Building an Enterprise IT Support System with GLPI

AbdulGoniyy Adeleke Dare ・ Aug 6

100 Days of DevOps: A Quarter of the Way There and What I've Learned

25 Days of DevOps: How I Fought Imposter Syndrome and Built Real Momentum

AbdulGoniyy Adeleke Dare ・ Sep 2

25 Days of DevOps: How I Fought Imposter Syndrome and Built Real Momentum

It Started with a Whisper of Doubt

The Power of a Public Logbook

From Theory to Tangible Skills (The First 25 Days)

What I've Really Learned in 25 Days

A Massive Thank You!

On to the Next 75!

devops #100daysofdevops #kodekloud #linux #motivation #beginners

From Zero to Helpdesk Hero: Building an Enterprise IT Support System with GLPI

The "Simple" Weekend Project That Wasn't

Why GLPI? (And What Even Is It?)

Setting Up My Fictional Empire: Meet FakeCorp

The Technical Journey (AKA: How Many Ways Can Nginx Break?)

Phase 1: The "Easy" Installation

⚙️ Project Overview: `warp-support-cases`

⛓️ Case 3: `PATH` Misconfiguration