DEV Community: Derek Kahre

Making the Web Accessible: Fixing an Open-Source Nav Bar

Derek Kahre — Thu, 23 Jul 2026 13:19:12 +0000

Keeping the internet accessible is a huge passion of mine. Whenever I can, I love jumping into open-source projects to help teams who share that same mission!

Finding the Issue

Recently, I came across an open-source repo where the maintainers were asking for help—their navigation bar was giving screen-reader users a rough time. I cloned the project to my local machine, fired up a dev server on localhost:3000 using npm run dev, and got to work.

Testing & Implementing the Fix

With a little help from AI to brainstorm the best semantic structure, I added aria-label tags and updated the markup to give screen readers proper context. I re-tested the live local build using the WAVE Chrome extension, and sure enough, all the navbar accessibility alerts vanished—without breaking the site's layout!

It brings my heart genuine joy knowing I'm helping make the web a little more accessible for everyone. Onward!

Checking My Work: How I Audited My Chatbot's Database Security

Derek Kahre — Mon, 20 Jul 2026 14:27:49 +0000

I’ve been working on an exciting new chatbot project lately. While looking over my notes from last week, I noticed a reminder I left myself to check for security bugs and vulnerabilities.

I teamed up with AI to dig into the project and evaluate my setup. Here is how I double-checked my work to get some peace of mind:

1. Hunting for Leaked Keys

First, I wanted to make sure my secret database keys hadn't accidentally leaked into my public GitHub code. I used a handy trick by pressing the "." key on GitHub to open the web editor. From there, I ran a global project search for any restricted service strings or secret prefixes.

The Result: The repository was completely clean. Only the safe, public-facing anonymous keys were in the frontend code.

2. Checking the Supabase RLS Policy

Next, I jumped into my Supabase dashboard to look at my Row-Level Security (RLS) settings. When you are prototyping quickly, it is easy to accidentally give a table open access just to get it working.

The Fix: I verified that my chat logging table was set to a strict "Insert-Only" public policy. This means users can submit their chat text to the database, but they cannot read, update, or delete anyone else's data.

Wrapping Up

It is a great feeling to check off that security item and know the database is handled responsibly. Building with AI lets you move incredibly fast, but taking the time to audit the backend is where the real learning happens.

How do you guys like to double-check your work or audit your database settings when you're building? Let me know in the comments!

From Legos to Referees: A Brief History of How Online Games Actually Work

Derek Kahre — Fri, 17 Jul 2026 19:02:48 +0000

Have you ever wondered what’s actually happening behind the scenes when you're staring at a mobile loading screen, or why players suddenly "teleport" backward when your Wi-Fi hiccups?

Making a game talk to players all over the world is a massive puzzle. Over the last 25 years, developers and hackers have played a high-stakes chess match to figure out the best way to build digital worlds. Here is the secret history of how online gaming evolved from simple web pages to massive multiplayer universes.

Phase 1: The "Wooden Block" Era (The Early 2000s)

Back in the early days of the internet, games like Neopets' NeoQuest didn't have smooth graphics or fancy apps. They were built using standard web server tools.

Every single time you took a step or swung a sword, your web browser had to completely reload a brand-new page. The game's "brain" lived on a server far away, which would take your move, update a giant digital spreadsheet (a database) tracking your stats, and send a whole new webpage back to your screen. It was clunky, but it meant your game automatically saved exactly where you left off, even if you shut down your computer for months.

Phase 2: The All-In-One Box (The Flash Era)

Soon, players wanted faster, smoother gameplay. Enter Adobe Flash. Instead of waiting for a server to load a new page every second, websites started sending your computer a single, self-contained file.

Inside this file was everything: the graphics, the sound, and the programming brain. Because it ran entirely inside your computer's local memory, the games were lightning-fast. The only time the game talked to the internet was at the very end to say, "Hey, this player just scored 1,500 points, go save it to their profile!"

The catch? Because the game's brain lived entirely on the player's computer, clever hackers figured out they could manipulate their computer's memory to instantly change their score to 999,999. Game developers fought back with "sanity checks" (code that auto-banned impossible scores) and encryption codes, starting a decade-long game of cat-and-mouse with cheaters.

Phase 3: The Ultimate Referee (Modern Mobile & Multiplayer)

To finally achieve checkmate against hackers, modern gaming moved the entire game board away from the player's device. Today, games use two main architectures to connect players:

The Client-Server Model
Used by massive games like Hearthstone or Fortnite, your phone acts as a basic screen and controller, but a powerful cloud server acts as the Ultimate Referee. When you tap "Attack," your phone asks the server for permission. The server calculates the math, decides if the hit was legal, and commands everyone's phones to show the result. It completely stops cheating, but renting these massive server computers globally costs millions of dollars.
The Peer-to-Peer (P2P) Model
To save money, some games—even fast-paced ones like Mario Kart—skip the expensive gameplay servers. Instead, they use a lightweight Matchmaking Server just to act as a digital dating agency, dropping players into a lobby together. Once the match starts, the server leaves, and the players' devices talk directly to each other.

Because there is no official referee, the devices have to constantly guess and predict where other players are moving. When the connection stutters, the illusion breaks, causing "phantom hits" or characters magically teleporting across the screen.

The Modern App Blueprint

Today, whether an app is built for iOS or Android, developers use standard building blocks to manage this chaos. They weave together UI components (the graphics you see), programming brains (like Swift or Kotlin), and APIs (the tools that let apps talk to your phone's hardware, like its GPS or pedometer).

From hand-carving text-based web pages to orchestrating millions of devices talking to each other in milliseconds, online gaming has turned into an incredible feat of engineering—all so you can slay dragons with your friends from the comfort of your couch.

The Role of Calibration When Deploying AI in Faith Spaces

Derek Kahre — Mon, 13 Jul 2026 16:11:17 +0000

The Role of Calibration When Deploying AI in Faith Spaces

I’ve been spending a lot of time lately building with AI—specifically wrestling with cloud databases and chatbot integration. But a recent engineering report caught my eye that made me step back and think about what we are actually building.

The Findings: Benchmarking Human Flourishing

Gloo recently released their second Flourishing AI Initiative (FAI) Insights Report. Instead of testing how fast or smart an AI is, they analyzed how well 36 major AI models align with a Christian worldview when answering deep questions about character, relationships, meaning, and faith.

The core takeaway really stuck with me: AI models show a massive gap in performance when moving from general human topics to a Christian worldview lens.

The Core Challenge: Procedural Secularism

As leading AI models strive to be "neutral and unbiased," they naturally default to a secular perspective. They handle daily logistics like health and finances incredibly well, but they consistently drift or flatten out when asked to engage with value-laden, theological, or spiritually sensitive questions.

Practical Considerations for Tech Builders

For developers and organizations building tools for faith-based spaces, this highlights an important design consideration. Within the church, conversations around AI can easily lean toward fear or outright rejection of the technology. But this data gives us a practical, objective look at what is actually happening: the models aren't necessarily malicious, but they are calibrated toward secular defaults.

The goal isn't to force Big Tech to adopt a specific religious framework. The goal is for those of us building tools for faith communities to understand these defaults so we can evaluate, safeguard, and build responsibly.

Let's Discuss

Have you noticed worldview drift in the AI models you use? How is your team handling values-alignment?

Building with AI, Engineering the Fix: Shipping a Chatbot to GitHub Pages

Derek Kahre — Sat, 11 Jul 2026 17:07:10 +0000

"I’ve been getting back into flexing my developer muscles after an extended break, and I thought what better way to start than building something with today’s AI tools? The landscape has changed so much since I last coded—I'm so glad I don't have to scour dozens of search results just to find a simple fix anymore.

The 20-Minute Sandbox Build

To kick things off, I decided to build a basic chatbot. Using Bolt.new, I prompted what I wanted, and it compiled the initial code in about 20 minutes.

Moving to Production: Where the Real Engineering Began

Of course, getting it working in Bolt’s local sandbox was the easy part. The real work started when I tried to deploy it to my GitHub repository. Because GitHub Pages handles paths differently, the build broke immediately.

That's where the modern AI workflow really shines. Instead of slogging through endless forums for "why is my path breaking," I was able to use AI to help diagnose the configuration issues, fix the relative paths in my JSON objects, and securely wire up my Supabase backend token.

Check Out the Project

You can check out the project here.

For those of you who have been in the game for a while, what has it been like adapting your workflow to AI development versus the old way of doing things?"

Fixing the "Invisible" Accessibility Bug: Cumulative Layout Shift (CLS)

Derek Kahre — Mon, 06 Jul 2026 23:11:00 +0000

When we think about web accessibility, we usually think about adding alt text to images or ensuring color contrast is high enough. But this week, while building out the skeleton for a responsive, accessible toy store project, a strict scanner taught me about an "invisible" accessibility bug that completely changes how a page feels to a user.

I deployed my initial HTML structure to GitHub Pages and ran it through Powermapper (SortSite). While basic checkers gave me a pass, Powermapper flagged a warning about missing image width and height dimensions.

At first glance, it feels like a minor layout issue, but it's actually an accessibility hurdle known as Cumulative Layout Shift (CLS).

The Problem: Jumping Layouts
When you omit image dimensions, the browser assumes the image takes up 0 pixels of space until the file completely downloads. The moment the image pops in, it violently pushes all the content below it down the screen.

For a user utilizing screen magnification software, or someone with motor-control challenges trying to click a button, that sudden "jump" can make them completely lose their place or accidentally click the wrong element.

The "A-Ha" Fix
To fix this without breaking your responsive design on mobile, you have to let the browser pre-calculate the aspect ratio box before the image loads. You do this by combining native HTML attributes with a tiny splash of CSS.

Here is the exact pattern that cleared the error:

HTML

 /* This ensures the image stays fluid and shrinks on mobile screens */ img { max-width: 100%; height: auto; } 


alt="Set of rocks with distinct tactile textures."
width="300"
height="300">

By putting the dimensions back in the HTML, the browser leaves a perfect placeholder box open while the image downloads. No shifting, no jumping, and a completely stable reading experience.

If you are auditing your own junior projects, I highly recommend throwing them into a stricter scanner like Powermapper to see what layout vulnerabilities might be hiding in plain sight.

Hopefully, this saves someone else a few hours of head-scratching today! What's an "invisible" bug a compiler or scanner has caught for you recently?