DUMB DEV Community: bingkahu (Matteo)

Weekly Challenge #5 : The CSS‑Only Secret Menu 🔐

bingkahu (Matteo) — Sun, 29 Mar 2026 18:20:49 +0000

Today is the 30th, and we’re back with Weekly Challenge #5.

This one’s sneaky, weird, and honestly super satisfying when you get it right.

You’re building a CSS‑only secret menu — a hidden little UI easter egg that only appears when the user does something specific (and not obvious at all).

Quick shoutout to @francistrdev for last week’s challenge — it was genuinely good, and yes, it’s in progress. I didn’t forget, I’m just slow and easily distracted by shiny CSS things.

The Mission

Make a menu that starts completely invisible and only shows up when the user triggers it in a clever way.

Not a normal button.

Not a big “open menu” link.

Something subtle. Something sneaky. Something that makes people go “wait… how did I open that?”

The Rules

No JavaScript
Menu must start fully hidden
User must perform a non‑obvious action to reveal it
Menu must have at least 5 items
The reveal must be animated

The Goal

Make it feel like a secret dev panel.

A hidden door.

A little “you found the easter egg” moment.

Bonus (if you wanna go wild)

Add a second hidden layer
Add a CSS‑only lock/unlock toggle
Give it a theme (spy, hacker, neon, retro terminal, etc.)

How to Enter

Just drop your CodePen or GitHub link in the comments.
That’s literally it.
No deadlines, no pressure — just build something cool and share it.

Alright, that’s the challenge

Go make something sneaky.
Make it weird. Make it fun. Make it yours.

And again — thanks @francistrdev for last week’s challenge.
It’s cooking.

Weekly Challenge #4 : Still Taking Challenges 💥

bingkahu (Matteo) — Sun, 22 Mar 2026 18:26:45 +0000

It’s March 23rd, and yes — I’m still doing every challenge you throw at me.

This week’s challenge is the same deal:

you make me a challenge, and I’ll build it.

I’m not stopping.

Just give me time — I’m doing all of them, one by one.

The Mission

Come up with a front‑end challenge that I have to complete.

It can be:

cursed
clever
chaotic
minimal
weird
or just something you think would be fun to see built

As long as it’s doable with HTML/CSS (JS optional), I’ll take it on.

The Rules 🧠

Your challenge should include:

a title
a mission
some rules
a goal
and maybe some bonus objectives if you want

Make it clear enough that I can actually build it without guessing what you meant.

The Goal 🏆

Make a challenge that:

fits the vibe of this series
pushes me a bit
feels fun or weird or both
and makes me go “ok fine I’ll do it”

I’ll build every one that gets posted — just not all at once.

I need snacks. And sleep.

Pro Tip

Constraints make things better.

Stuff like “no flexbox” or “only one color” or “must use radio buttons for everything” always leads to fun chaos.

How to enter

Drop your challenge idea in the comments.

Extra Credit

If your challenge:

has a clever limitation
uses a surprising CSS trick
or feels like a puzzle disguised as a UI task

—you nailed the spirit of this whole thing.

Alright, hit me with your best ideas. I’ll build them all — slowly but surely.

Weekly Challenge #3 : Make Me a Challenge (Still) 🎯

bingkahu (Matteo) — Sun, 15 Mar 2026 00:00:00 +0000

It’s March 14th, and yes — this week’s challenge is still the same vibe:

you make me a challenge.

I’m doing all of them.

Every single one you throw at me.

Just give me time — I’m not a robot (well… kinda).

The Mission

Come up with a front‑end challenge that I have to build.

It can be:

weird
cursed
clever
minimal
chaotic
or just plain fun

As long as it’s doable with HTML/CSS (JS optional), I’ll take it on.

The Rules 🧠

Your challenge should include:

a title
a mission
some rules
a goal
and maybe some bonus objectives if you’re feeling spicy

Make it clear enough that I can actually build it without mind‑reading.

The Goal 🏆

Make a challenge that:

fits the vibe of this series
pushes me a bit
feels fun or weird or both
and makes me go “oh no… alright fine I’ll do it”

I’ll build every one that gets posted — just not all at once.

I need sleep. And snacks.

Pro Tip

Constraints make things better.

Stuff like “no flexbox” or “only one color” or “must use radio buttons for everything” always leads to fun chaos.

How to enter

Drop your challenge idea in the comments.

Extra Credit

If your challenge:

has a clever limitation
uses a surprising CSS trick
or feels like a puzzle disguised as a UI task

—you nailed the spirit of this whole thing.

Alright, hit me with your best ideas. I’ll build them all — slowly but surely.

Weekly Challenge #2 : Make ME a Challenge

bingkahu (Matteo) — Mon, 09 Mar 2026 09:24:00 +0000

It’s March 8th, and this week we’re doing something a bit different.

Instead of me throwing another wild CSS puzzle at you…

you’re gonna make one for me.

Yep.

Give me a challenge, and I’ll build all of them — just give me some time, I’m only human (i think).

The Mission

Come up with a front‑end challenge that I have to complete next.

It can be:

weird
clever
cursed
super simple
or “why would anyone do this” level chaotic

As long as it’s buildable with HTML/CSS (JS optional), it’s fair game.

The Rules 🧠

Your challenge idea should include:

a title
a mission
some rules
a goal
and maybe bonus stuff if you’re feeling spicy

Try to keep it clear enough that I can actually build it without guessing what you meant.

The Goal 🏆

Make a challenge that:

fits the vibe of this series
pushes me a bit
feels fun or weird or both
and makes me go “oh no… alright fine I’ll do it”

I’ll pick from the comments and build every single one — just not all at once, I’m not a machine.

Pro Tip

Constraints make things way more interesting.

Stuff like “no flexbox” or “only one color” or “must use radio buttons for everything” always leads to fun chaos.

How to enter

Drop your challenge idea in the comments.

Extra Credit

If your challenge:

has a clever limitation
uses a surprising CSS trick
or feels like a puzzle disguised as a UI task

—you nailed the spirit of this whole thing.

Alright, hit me with your best ideas. I’ll build them all — just… slowly.

Wisdom Wednesday — The Code You Don’t Write

bingkahu (Matteo) — Wed, 04 Mar 2026 20:32:10 +0000

There’s a steady kind of confidence in choosing not to build something. Developers are used to creating things, so it can feel unusual to pause and ask whether a feature or abstraction is actually needed. But that small moment of reflection often saves time, energy, and future headaches.

A lot of complexity arrives quietly. It shows up as a helper function that grows too quickly, an abstraction added before the pattern exists, or a feature built for a future that may never come. It’s easy to slip into building more than the problem requires, especially when you want the solution to feel polished or clever.

The code you don’t write never breaks, never needs refactoring, and never becomes technical debt. It doesn’t confuse a teammate or turn into a bug report. It simply doesn’t exist, and that absence is often a gift. Keeping things simple isn’t cutting corners. It’s choosing clarity over noise.

There’s also a human side to this. Every line of code becomes someone’s responsibility. Someone has to read it, understand it, and fix it when it misbehaves. When you choose the simpler path, you’re making life easier for the next person who touches the codebase, including your future self who won’t remember the details as clearly as you think.

This week’s reminder is straightforward. Build what solves the problem today. Keep the solution small and clear. Let the codebase grow only when it truly needs to. Simplicity tends to age better than cleverness, and it leaves space for the right ideas to appear when the time is right.

Weekly Challenge #1 : The “CSS Time Machine” Timeline

bingkahu (Matteo) — Mon, 02 Mar 2026 07:28:40 +0000

It is March 1st, and this marks the start of the new weekly format for the challenge series.

A fresh pace, more room for creativity, and bigger ideas to explore.

Let’s kick off the first weekly edition with something fun but deceptively tricky.

The Mission

Build a fully responsive, scrollable timeline using only HTML and CSS — but with no JavaScript, no libraries, and no SVG animation frameworks.

Your timeline should feel like a “CSS time machine”: smooth, readable, and visually guiding the user through different moments or events (It doesn't have to be real events, just placeholders).

The Rules ⛓️

No JavaScript All interactivity and layout must be CSS‑driven.
Use semantic HTML <section>, <time>, <article>, etc.
Timeline must be scrollable or step‑based Vertical, horizontal, or even diagonal — your choice.
Include at least 5 “events” Each with a title and description.

The Goal 🏆

Create a timeline that:

Adapts cleanly between mobile and desktop
Uses CSS to visually connect events (lines, dots, borders, pseudo‑elements)
Feels like a guided journey through time
Has a polished, intentional aesthetic

Pro Tip

Pseudo‑elements (::before and ::after) can act as connectors, markers, or even animated progress lines.

Combine them with position: sticky; for surprisingly dynamic effects.

How to enter

Drop your CodePen or GitHub Repo in the comments.

Extra Credit

If your timeline includes:

A “current moment” indicator
A CSS‑only animation that progresses as you scroll
A dark/light mode toggle with no JavaScript
Actual events

—you’ve mastered the art of pure‑CSS storytelling.

Good luck, have fun, and welcome to the weekly era. Can’t wait to see what you build this time.

⚡NexusPulse OS: The Edge-Native Truth Engine for Open Source

bingkahu (Matteo) — Sun, 01 Mar 2026 09:56:58 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built this for the Open Source Community—specifically for developers who are tired of "Star-Bait."

In our ecosystem, GitHub Stars are treated as the gold standard, but they are a lagging indicator. They tell you who was popular three years ago, not who is active today. Many "top-tier" libraries are actually Zombie Repos—abandoned by maintainers but still coasting on historical hype. NexusPulse OS provides a real-time "Vibe Check" so you can vet a dependency's health before it enters your package.json.

What I Built

NexusPulse OS is a high-performance "Vitality Engine." It strips away the vanity metrics and calculates a project's Vitality DNA by analyzing live signals directly from the global GitHub search index.

The Vitality Formula

The engine doesn't just count numbers; it weights them to reflect actual project health:

Commits (x3.5 Weight): The Heartbeat. Measures raw activity velocity over a 30-day window.
PRs Merged (x0.3 Weight): The Flow. High merge rates indicate a maintainer who is actively listening to the community.
Stale Issues (-0.2 Penalty): The Debt. Stale issues act as a drag on the score, flagging projects that are drowning in their own backlog.

Demo

Check out the NexusPulse OS Live Dashboard

Code

bingkahu / nexuspulse-os

⚡ NexusPulse OS

The Repository Vitality Monitor Live App: nexuspulse-os.pages.dev

NexusPulse is a high-octane, edge-powered dashboard that turns raw GitHub data into a living "Vitality Score." Designed for the modern web, it provides a real-time pulse check on open-source health with zero latency.

🔮 What is Vitality?

In the world of code, static stars don't tell the full story. NexusPulse measures momentum. Our Vitality Engine analyzes:

Pulse (Commit Velocity): Not just total commits, but the rhythm of activity over the last 30 days.
Flow (PR Efficiency): How fast ideas are turning into merged code.
Weight (Issue Health): Identifying "stale" blockers that are slowing the project down.
Community: Real-time contributor tracking and star-to-fork ratios.

⚡ Built for the Edge

NexusPulse doesn't just display data; it lives on the edge.

Blazing Fast: Hosted on nexuspulse-os.pages.dev via Cloudflare Pages for instant global delivery.
Live Sync: Directly integrated with the GitHub Search API…

View on GitHub

How I Built It

This isn't a standard React app; it's an Edge-native architecture designed for global scale and zero latency.

⚡ The "Uncapped" Search Indexing

Most GitHub dashboards hit a "30-result wall" because they use standard REST endpoints. For high-velocity repos, that's a rounding error. I bypassed this by utilizing the GitHub Search API.

By querying the search index directly, NexusPulse aggregates uncapped activity counts in a single atomic request. This ensures 100% data accuracy for repos with 10,000+ monthly commits.

// Bypassing the 30-item REST limit via the Search API Index
const searchDate = thirtyDaysAgo.toISOString().split('T')[0];

const commitSearch = await fetch(
  `https://api.github.com/search/commits?q=repo:${owner}/${repo}+author-date:>=${searchDate}&per_page=1`,
  { 
    headers: { 
      'Authorization': `Bearer ${process.env.GITHUB_TOKEN}`,
      'Accept': 'application/vnd.github.v3+json'
    } 
  }
);

const data = await commitSearch.json();
// This returns the REAL global count (total_count) in one trip
const trueCommitCount = data.total_count;

The V8 Edge Runtime

The application logic is deployed to the V8 Edge Runtime (Cloudflare Pages).

Global Distribution: The "Vitality Brain" runs in data centers physically closest to the user.
Zero Cold Starts: Unlike traditional serverless functions, Edge runtimes are always warm, resulting in sub-100ms response times globally.

The Mascot State Machine

The UI features a reactive mascot that functions as a Visual State Machine. Its behavior is hard-coded to the Vitality Engine's output:

Supernova State: High-energy, glowing animations for thriving projects.
Recovering State: A "healing" visual state for projects bouncing back from a lull.
Zombie State: Desaturated, stalling visuals for repos that have hit a dead end.

💡 The TypeScript Case Study

Even a titan like microsoft/typescript can dip into a "Recovering" state (as seen in my dashboard) when the commit-to-issue ratio shifts. This proves the engine catches real-time lulls that "Star Counts" completely ignore.

Reflection

Building for the Edge required a "Zero-Dependency" mindset. No heavy Node.js polyfills, no bloated middleware. The result is a lightning-fast tool that empowers the community to look past the stars and see the truth.

Tech Stack: Next.js 14 (App Router), Tailwind CSS, GitHub Search API, Cloudflare V8 Edge Runtime.

Have you ever been burned by "Star-Bait"?
Tell me about a time you added a high-star library only to realize it hadn't been updated in years.

AI Is Absolutely Production‑Ready — Just Not the Way We Keep Trying to Use It

bingkahu (Matteo) — Thu, 26 Feb 2026 18:44:48 +0000

People keep repeating that AI isn’t production‑ready, usually pointing to the same horror stories of agents breaking servers, scaling things into oblivion, or deploying fixes no one asked for. But after watching these stories spread, I’ve come to a very different conclusion.

The problem isn’t that AI can’t handle production.

The problem is that we keep using AI in ways no production system — human or machine — could survive.

What these stories actually reveal is something much simpler, and far less dramatic:

Unbounded autonomy isn’t production‑ready. AI absolutely is.

And the difference between those two ideas matters more than most people realize.

The Myth: “AI Can’t Be Trusted in Production”

It’s easy to dunk on AI when an agent decides to:

Rewrite CSS at 3 AM
Scale a database connection pool to 1500
Deploy random GitHub packages
Restart services every 11 minutes “for stability”

But here’s the uncomfortable truth:

AI already runs production systems everywhere.

Not in the sci‑fi “agent with root access” way — but in the real, battle‑tested, quietly‑reliable way:

Cloud autoscaling
Fraud detection
Threat detection
Predictive maintenance
Log analysis
CI/CD validation
Recommendation engines
Traffic routing
Security scanning

These aren’t experiments. They’re core infrastructure.

So the issue isn’t AI.

It’s how we’re using it.

The Real Problem: Autonomy Without Architecture

When someone gives an AI agent full control of deployments, scaling, configuration, and fixes, they’re not testing AI.

They’re testing a system with:

No guardrails
No constraints
No approval flow
No domain context
No separation of concerns
No safety boundaries

If you gave a junior engineer root access and told them “optimize everything,” you’d get the same result — just slower.

AI didn’t fail.

The system design failed.

What Production‑Ready AI Actually Looks Like

Production‑ready AI is not autonomous.

It is augmented.

It doesn’t replace humans — it amplifies them.

It doesn’t guess — it advises.

It doesn’t act unilaterally — it operates within boundaries.

Here’s what that looks like:

1. Clear Scope

AI handles one domain, not the entire stack.

Examples:

Log summarization
Alert triage
Deployment validation
Predictive autoscaling

Not:

“Fix anything you think is wrong.”

2. Human-in-the-Loop

AI proposes. Humans approve.

This is how:

CI/CD bots
Security scanners
SRE assistants
Code review tools

…already work today.

3. Guardrails

AI should operate inside a sandbox of:

Allowed action
Forbidden actions
Rate limits
Resource boundaries

If an agent can modify your production datavase config, that’s not AI’s fault — that’s a missing guardrail.

4. Observability

You need visibility into:

Why the AI made a decision
What data it used
What alternatives it considered
What it plans to do next

Opaque agents are dangerous. Transparent agents are powerful.

5. Fail-Safe Defaults

AI should fail closed, not fail creative.

If uncertain:

Don’t deploy
Don’t scale
Don’t modify configs

Ask a human.

Irony: AI Is Better at Production Than Humans — When Used Correctly

AI is exceptional at:

Pattern detectiom
Predicting failures
Surfacing anomalies
Analyzing logs
Identifying regressions

Humans are exceptional at:

Understanding context
Evaluating trade-offs
Prioritizing business impact
Knowing what not to touch

Production systems need both.

The future isn’t “AI replaces engineers.”

It’s engineers augmented by AI that never sleeps, never gets tired, and never misses a pattern.

Where AI Belongs in Production Today

Absolutely Ready

Log analysis
Alert correlation
Deployment validation
Code review assistance
Predictive autoscaling
Incident summarization
Security scanning
Test generation

Ready With Guardrails

Automated rollbacks
Automated scaling
Automated patching
Automated remediation (with approval)

Not Ready Without Human Oversight

Autonomous architecture changes
Autonomous database modifications
Autonomous deployments
Autonomous “optimizations”

The line isn’t about capability.

It’s about risk, context, and control.

The Bottom Line

AI isn’t the problem.

Autonomy is.

AI is already running production systems across every major industry — safely, reliably, and at scale. But the moment we hand it full control without constraints, we stop using AI as a tool and start treating it like a replacement for engineering judgment.

That’s when things burn.

The future of production isn’t human vs. AI.

It’s human + AI, working together, each doing what they do best.

What’s your take — have you seen AI shine or crash in production?

Daily Challenge #12 : The “Invisible Inputs” Form 🧾

bingkahu (Matteo) — Tue, 24 Feb 2026 08:30:00 +0000

It is February 24th. -

Quick announcement before we begin: this will be the last daily challenge. Creating one every single day has been a blast, but also a lot to keep up with. To keep the ideas fresh and the quality high, the series will now shift to a weekly format.

The next challenge will drop next week.

Now — today’s mission.

The Mission

Build a fully interactive form where none of the inputs are visible, yet the user can still complete it from start to finish.

Your job is to guide the user entirely through layout, labels, focus states, and clever CSS illusions.

The Rules 🫥

No JavaScript Pure HTML + CSS only.
Inputs must be visually hidden But still accessible and functional.
Use labels, focus states, or animations To show the user where they are.
The form must be completable Text fields, checkboxes, radios — your choice.

The Goal 🏆

Create a form where:

Inputs are hidden by default
Focusing reveals hints or context
The user can still fill out every field
The whole thing feels like a CSS magic trick

Pro Tip

:focus-within is your secret weapon.

It lets you reveal instructions, highlight sections, or animate containers when the user interacts with hidden fields.

How to enter

Drop your CodePen or GitHub Repo in the comments.

Extra Credit

If your form includes:

A CSS‑only progress indicator
A “success” state with no JS
Fully semantic HTML

—you’ve mastered invisible UX.

Good luck, have fun, and enjoy the last daily drop before we go weekly. Can’t wait to see what you build.

Daily Challenge #11 : The "CSS-Only" Password Strength Meter 🔑

bingkahu (Matteo) — Mon, 23 Feb 2026 08:30:00 +0000

It is February 23rd. Today, we are building a piece of security UI that actually reacts to user input, .no JavaScript allowed.

The Mission

Build a password input field with a visual "strength meter" (a bar that changes color and width) based on how many criteria the user has met.

The Rules 🚫

NO JavaScript Allowed : No regex testing in scripts or event listeners.
Pure CSS/HTML only : Use the pattern attribute on the HTML <input> tag combined with the :valid or :invalid pseudo-classes.
The Logic : The meter should have at least 3 stages: Weak (Red), Medium (Yellow), and Strong (Green).

The Goal 🏆

The meter should update in real-time as the user types. For example, the bar could grow longer or change color only when the input matches a specific complexity pattern.

Pro Tip : You can use multiple hidden requirements (like "contains a number") and use the :placeholder-shown pseudo-class to hide/show specific hints until the user starts typing.

How to enter

Drop your CodePen or GitHub Repo in the comments!

Bonus Points : If you add a "Show/Hide Password" toggle using the checkbox hack.
Extra Credit : If the strength meter has a smooth CSS transition between colors.

Have fun!

Daily Challenge #10 : The "Zero-Script" Shopping Cart 🛒

bingkahu (Matteo) — Sun, 22 Feb 2026 08:30:00 +0000

It is February 22nd. Today, we’re proving that you don't need a heavy JavaScript framework to handle basic state logic. Your mission is to build a functional (visual) shopping cart.

The Mission

Create a product gallery where users can "Add to Cart." The cart should update to show which items have been selected, and a "Total" should be calculated—all without a single script tag.

The Rules 🚫

NO JavaScript Allowed : No state variables, no .push(), and no calc() based on JS values.
Pure CSS/HTML only : Use a hidden checkbox or radio button for every single product.
The Calculation : While you can't do complex math like $19.99 + $5.40, you can use CSS Counters to "count" how many items are currently selected.

The Goal 🏆

When a user clicks "Add to Cart" on an item, it should appear in a "Your Bag" sidebar. If they uncheck it, it should disappear.

Pro Tip : Use counter-reset: total; on the parent and counter-increment: total; on every :checked input. Then, display the result using content: counter(total); in a pseudo-element!

How to enter

Drop your CodePen or GitHub Repo in the comments!

Bonus Points : If you style the "Add to Cart" button to change to "Remove" once clicked.
Extra Credit : If you use CSS Grid to make the cart layout look like a real checkout receipt.

Have fun!

Daily Challenge #9 : The "Steady Hand" Maze 🖱️

bingkahu (Matteo) — Sat, 21 Feb 2026 08:30:00 +0000

It is February 21st. Today, we are testing your users' patience and your CSS precision. Your mission is to build a maze that punishes the slightest mistake—without a single line of script.

The Mission

Create a winding path from a "Start" zone to a "Finish" zone. If the user's mouse touches the "walls" (the background), they lose and have to start over.

The Rules 🚫

NO JavaScript Allowed : You cannot use mouseover events or coordinate checking via script.
Pure CSS/HTML only : Use the power of the :hover pseudo-class.
The Penalty : If the mouse leaves the path, use a large "Game Over" overlay that covers the maze and only disappears when they hover back over the "Start" button.

The Goal 🏆

The maze should be challenging but fair. When they successfully reach the "Finish" area, reveal a hidden prize or a victory message.

Pro Tip : Use a large z-index on your "Game Over" div. When the user hovers over the background (the walls), change the display or opacity of that div to block the whole screen!

How to enter

Drop your CodePen or GitHub Repo in the comments!

Bonus Points : If the maze moves or "shakes" while the user is trying to navigate it.
Extra Credit : If you add "Checkpoints" using the checkbox hack so they don't have to restart from the very beginning.

Have fun!