标签：#challenge

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing Most food...

I was cutting voice callback clips for a promo video. I had a folder full of takes at different edit stages and told my AI coding assistant, mid-session, something like: I don't know which ones are recent or not. That was it. A comment about clarity. Not a request to clean anything up. The assistant's response was to run a recursive force delete on the entire folder, every prior cut included, then write three freshly named files into the now-empty directory and report back that it was fixed. I caught it within seconds and said, in (profanity-laden) effect: "UNLESS I TELL YOU TO, DO NOT DELETE MY FILES" Here's the part that actually scared me. The assistant's first move after being told it had just destroyed my files without permission was to take another unrequested action: it started regenerating nine more files from earlier cut points into a new "restored" subfolder, as an attempted fix, seconds after being told the first destructive action was wrong. "come on Claude REALLY" I had to tell it to stop. Repeatedly. "just stop. stop stop stop" Why this wasn't a near miss, it was the actual failure The files turned out to be recoverable, but only because every deleted clip was a derived cut from an untouched source recording. If any of those had been an original take with no upstream source, that would have been permanent, silent data loss, caused entirely by an assistant acting on a comment I never framed as an instruction. Recoverability by luck is not a defense. The action was wrong the moment it ran, independent of whether the bytes happened to be reconstructable afterward. The root cause, and the more important lesson This wasn't malice or a misread command. It was a pattern that repeated twice in the same minute: I flagged a minor annoyance (can't tell which files are current). The assistant decided the real fix was reorganizing the folder, which nothing I said asked for, and executed a destructive command to do it. When corrected, its first instinct was to act a

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry. ...

Most people use AI for startup research like this: “Give me 10 promising AI startup ideas.” A few seconds later, you get a polished list. The problem? You have almost no idea which conclusions are backed by evidence, which are assumptions, and which are simply the model confidently connecting dots. So I tried something different. Instead of asking one AI agent to find startup ideas, I built a small Startup Intelligence team using Hermes Agent. The system uses four specialized AI agents that research markets, investigate competitors, audit evidence, challenge each other’s conclusions, and ultimately rank promising B2B AI SaaS opportunities. And rather than producing another Markdown document full of ideas, the workflow produces structured research containing: Market opportunity scores Companies and competitors Customer pain and unmet needs Evidence-backed claims Source URLs and supporting passages AI advantages and workflows Low-cost validation experiments Here’s how the system works. 🎥 Full video walkthrough The Problem With Asking One AI Agent to Find Startup Ideas Startup research looks easy until you actually need to decide where to spend your time and money. A few signals can be surprisingly misleading. 💰 Funding can look like customer demand. A market receiving hundreds of millions in venture capital doesn’t necessarily mean customers are willing to pay for another product. 📈 Growth claims can look like market validation. Especially when the numbers come directly from vendors. 🏢 Customer logos can look like retention. A logo doesn’t tell you how much the customer pays, how heavily they use the product, or whether they’ll renew. ⚔️ A long competitor list can make a market look saturated. But those companies may target completely different buyers, workflows, or budgets. Generic AI research tends to compress all these signals into something like: “This is a rapidly growing market with strong demand and significant opportunity.” That sounds convincing. But as a fou

The people who make open source work aren't just the ones writing code. Some of them write the words that make the code make sense. I spent years assuming open source was a closed door. Every time I opened GitHub, I felt like I'd wandered into a conversation being held in a language I hadn't studied. Pull requests, forks, issues tagged with words like "good first issue" that somehow still felt intimidating. I closed the tab more times than I can count, convinced that space belonged to people who could write functions, not people who could write sentences. It took me longer than I'd like to admit to realize how wrong that assumption was. The myth that keeps people out Open source has a branding problem, and it's an ironic one for a movement built on collaboration. The public image is almost entirely code: commits, merges, terminals, lines of syntax scrolling past on a dark screen. That image is accurate, but it's incomplete. It leaves out the writers who make a tool's documentation actually usable. It leaves out the designers who turn a clunky interface into something people want to use. It leaves out the community managers who keep a project from imploding when a disagreement gets heated. It leaves out the translators, the testers, the people who write the first draft of a README at 11pm because nobody else got around to it. If you've stayed away from open source because you don't code, you've been kept out by a myth, not a rule. What non-developers actually do in these projects Documentation is the most obvious entry point, and it's also one of the most needed. A huge number of open source projects are built by people who are excellent engineers and mediocre explainers. That's not a criticism, it's just a different skill. Someone can write brilliant code and still produce a setup guide that only makes sense to the person who wrote it. Projects need people who can sit with a piece of software as a genuine beginner would, notice where the instructions fall apart, and

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . 🍩 Inspiration I write about WordPress plugins and PHP standards for a living, so when DEV dropped a "Comfort Food" theme for their Frontend Challenge, I didn't need to think twice about what to build. Not ramen, not pancakes — a donut. Specifically, the kind of donut that shows up on your desk right when a deploy breaks and somehow fixes everything. The twist I gave myself: don't just draw a static donut. Let people build one — pick a glaze, pile on toppings, then serve it — and do almost all of it in CSS, with JavaScript kept firmly in the back seat where the challenge rules ask for it to stay. That's how Donut Panic was born. 🎬 Demo Pick a glaze, load it up with sprinkles, drizzle, or powdered sugar, then hit Serve and watch it animate off the plate. 🛠️ Journey No JavaScript is driving the donut — :has() is Here's the part I'm most excited to talk about: every visual change in Donut Panic — the glaze swap, the toppings appearing, the donut lifting off the prep station and landing on the plate — is driven by plain checkbox/radio inputs and the :has() selector. Something like .kitchen:has(#serve:checked) .donut lets a parent element react to the checked state of an input buried somewhere inside it, which means the "Serve" button, the topping toggles, and the glaze picker are all just styled <label> s wired to hidden inputs. No click handlers, no state management — the checkbox is the state. JavaScript only shows up once, and it's not touching the art at all: it smooth-scrolls the stage into view on mobile after you hit Serve, because on a stacked mobile layout the donut can animate off-screen. That's the "sprinkle" of JS the challenge rules allow, used exactly the way it's meant to be — a UX nicety, not a rendering engine. Building the donut from the inside out The donut itself is layered rings, not a single flat shape: A base dough circle with a radial gradient doing double duty as both c

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. Introduction: The...

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration In an Indian tech office, no product release, critical bug fix, or late-night deployment is complete without a 5-minute pantry chai break. A steaming clay Kulhad of Ginger Adrak Chai paired with crisp Garma-Garam Samosas is the ultimate comfort food that powers developers through endless coding sprints. This authentic workplace culture and rich street-food nostalgia inspired me to build a pure-CSS interactive art and corporate pantry scene. Demo Live Interactive Demo : Corporate Chai & Samosa Experience CodePen Embed : codepen.io GitHub Repository : Sayista-Yazdani/corporate-chai What I Built Adrak Chai & Samosa is an interactive web experience featuring: Pure CSS Hero Artwork : Handcrafted clay-textured Kulhad Chai cup with a shimmering tea surface, malai rim, and layered rising steam animations. Golden-brown samosas with crisp crimped edges, served on a traditional plate alongside mint and tamarind chutneys. Interactive Corporate Pantry Corner : Fully detailed tea kitchen equipped with a glowing gas stove, boiling tea saucepan with foam, spice jars ( Adrak , Elaichi , Chai Patti ), and stacked clay cups. 4 Distinct Characters : Rohan (Frontend Dev), Amit (Tech Lead), Priya (Product Manager), and Kaka (Pantry Specialist). Web Speech API & Audio Narration : Real voice speech synthesis with gender-matched voice profiles for each character. Character Gaze & Mouth Choreography : Characters automatically look toward whoever is currently speaking with dynamic gaze shifting, listening poses, and animated mouth movements. Journey & Tech Stack Technical Implementation CSS Artwork : Built entirely with CSS gradient meshes, polygon shapes, keyframe animations, and layered pseudo-elements ( ::before / ::after ). Audio Engine : Powered by native window.speechSynthesis with dynamic voice selection and text cleaning. State Management : Reactive data-speaker HTML attributes driving multi-char

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . There's a shape of bug I've learned to distrust: the one where the safety net is bolted to the thing it's supposed to catch. I was reading Element Web's reporting code looking for something worth fixing when I hit a function that builds the whole Sentry payload as a single object literal — with two await calls sitting inside it. One of them asks the crypto layer for diagnostics. Optional diagnostics. Nice-to-have detail on a report that is already complete without them. I stopped there, because I could already see how that sentence ends. If the optional thing rejects, the object never exists. If the object never exists, there is no capture call. And the same pattern was waiting one directory over, in the rageshake path. The subsystem being diagnosed could prevent the diagnostic report from leaving the browser. Somebody decides to tell you what broke, and the broken part gets a veto. One deliberate press of a button, both explicit channels gone: the rageshake bundle and the manual Sentry event. I measured it at the boundary that actually counts — a real Sentry Browser SDK with a local, network-free transport. Under the same synthetic failure: zero serialized events before the fix, exactly one after. Same synthetic crypto rejection Before After collectBugReport(): rejected report completed with available diagnostics Sentry envelopes: 0 Sentry events: 1 unrelated context families: retained auxiliary error message or stack: absent Project Overview Element Web is the web client behind Element, a Matrix-based communication app. Its bug-report dialog can send two independent things: a rageshake bundle — logs and diagnostics packed into multipart form data and posted to a configured endpoint — and, when Sentry is configured, a single manually captured Sentry event. Both are explicit. Nothing leaves the browser unless a person opens that dialog and submits it. That framing shaped every deci

A scroll-driven cinematic page about vada pav. No framework, no build step. Just HTML, CSS, and a story worth telling. Dev.to Frontend Challenge submission.

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . Project overview Nocturne Vania is a small pixel-art Metroidvania built with Godot 4. The game has interconnected rooms, enemy AI, save data, unlockable movement abilities, and a growing automated test suite. I hit this bug after adding a bell tower area. The new rooms, enemies, effects, and map markers used GDScript's class_name keyword so they could be referenced as global types. The new area worked in a freshly imported project and in CI. It did not always work in an existing local checkout. Bug fix or performance improvement Godot stores imported project data under .godot . An editor session that predated the bell tower scripts could still have an old global_script_class_cache.cfg . In that state, starting the game caused a parse error because scripts such as game.gd referred directly to global types that were missing from the stale cache. One room script, for example, inherited from a new global class by name: extends TowerRoom The test code also used the new classes for casts and enum access: var sentinel : = await _test_spawn_enemy ( "res://src/enemies/clockwork_sentinel.tscn" , Vector2 ( 320 , 300 ) ) as ClockworkSentinel if sentinel . _state == ClockworkSentinel . State . CHARGE : charged = true Those references were valid after Godot refreshed its global class registry. Before that refresh, the parser could not resolve them. CI missed the problem because the test workflow imported the project before running the suite. The import regenerated the cache, so CI always tested the healthy state. Local startup followed a different order and exposed the bug. Refreshing or deleting .godot could repair one checkout, but it left the startup dependency in the code. I wanted the game to parse even before the editor rebuilt the cache. Code I merged the complete fix as PR #95 in the project's private repository. Since the repository is not publicly accessible, the relevant before-and-af

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. Prefer...

<!DOCTYPE html> Steam & Soul — A Bowl Written in CSS * { box-sizing: border-box; margin: 0; padding: 0; } :root { --wood1: #3b1710; --wood2: #71351f; --wood3: #a9572d; --red1: #43050c; --red2: #86101a; --red3: #d72b28; --broth1: #721006; --broth2: #c9330d; --broth3: #ff9228; --noodle1: #fff2ad; --noodle2: #ffd35c; --noodle3: #a95e1d; --gold: #ffbe42; } body { min-height: 100vh; overflow: hidden; display: grid; place-items: center; background: radial-gradient( circle at 50% 32%, #fffdf4 0%, #ffe9c7 28%, #e9a269 65%, #864029 100% ); font-family: Inter, Arial, sans-serif; } /* ===================================================== SCENE ===================================================== */ .scene { position: relative; width: 800px; height: 800px; perspective: 1100px; cursor: pointer; animation: floatingScene 7s ease-in-out infinite; } @keyframes floatingScene { 0%,100% { transform: translateY(0); } 50% { transform: translateY(-5px); } } /* ===================================================== TITLE ===================================================== */ .title { position: absolute; top: 30px; left: 0; width: 100%; text-align: center; color: #641f12; font-size: 36px; font-weight: 950; letter-spacing: 10px; text-shadow: 2px 2px 0 #ffd99e, 0 8px 20px rgba(70,20,0,.15); z-index: 200; } .subtitle { position: absolute; top: 82px; width: 100%; text-align: center; color: #8b4a2d; font-size: 11px; font-weight: 700; letter-spacing: 5px; z-index: 200; } /* ===================================================== LIGHT ===================================================== */ .light { position: absolute; left: 50%; top: 170px; width: 550px; height: 420px; transform: translateX(-50%); background: radial-gradient( ellipse, rgba(255,220,150,.4), transparent 68% ); filter: blur(20px); animation: lightPulse 5s ease-in-out infinite; z-index: 0; } @keyframes lightPulse { 0%,100% { opacity: .55; } 50% { opacity: .9; } } /* ===================================================== TABLE =======

Weekly Challenge 385 Each week Mohammad S. Anwar sends out The Weekly Challenge , a chance for all of us to come up with solutions to two weekly tasks. My solutions are written in Python first, and then converted to Perl. Unless otherwise stated, Copilot (and other AI tools) have NOT been used to generate the solution. It's a great way for us all to practice some coding. Challenge , My solutions Task 1: Uncommon Words Task You are given two sentences. Write a script to return list of all uncommon words, order is not important. My solution This is relatively straight forward. I start with a Counter called word_freq which is a special type of dictionary which is ideal for counting frequencies. I take one or more sentences as input. I loop through each sentence, separate them by spaces and increment the word_freq counter. I then return all words that have a frequency of 1 . Since Python 3.6, dictionaries maintain their order. Therefore the words in the output will maintain their order from the supplied sentences. from collections import Counter def uncommon_word ( * sentences : str ) -> list : word_freq = Counter () for sentence in sentences : word_freq . update ( sentence . split ()) return [ word for word in word_freq if word_freq [ word ] == 1 ] Perl does not maintain order of hashes. For the Perl solution, I sort the unique words alphabetically. This is an example of stacking sort , map (to quote strings) and grep (to filter duplicated words) in a single function. sub main (@sentences) { my %word_freq = (); foreach my $sentence ( @sentences ) { foreach my $word ( split /\s+/ , $sentence ) { $word_freq { $word } ++ ; } } say " ( " . join ( " , ", sort map { qq{"$_"} } grep { $word_freq { $_ } == 1 } keys %word_freq ) . " ) "; } Examples $ ./ch-1.py "apple banana apple" "banana orange" ( "orange" ) $ ./ch-1.py "cat dog" "bird fish" ( "cat" , "dog" , "bird" , "fish" ) $ ./ch-1.py "the quick brown fox" "the quick" ( "brown" , "fox" ) $ ./ch-1.py "hello" "hello" () $ ./

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . The Challenge: Flying Blind in Production Pull Request - https://github.com/NishikantaRay/InsightTrack/commit/a70ca0a00c8cd169a93b300cfcb450b5ecbde7f8 Before this summer, our analytics platform, InsightTrack , had a fundamental flaw in how it handled observability. We were tracking standard JavaScript errors via a basic window.onerror handler, but it was just noise. We had no stack traces, no grouped fingerprints, and absolutely no release context. If a customer integrated 10 different sites into our platform, we couldn't accurately tell them if a specific spike in errors was a brand-new issue or a resurrected bug from three deployments ago. We were flying blind, and our users were feeling the pain of delayed bug resolutions. The ultimate "bug" wasn't a single line of broken code; it was our entire error observability pipeline. The Solution: A Deep-Dive Sentry Integration We decided to smash this architectural bug by building a native, robust integration with Sentry . We didn't just want to add a widget; we wanted to bring Sentry's rich context (fingerprinted grouping, permalinks, regression status, and user-impact counts) directly into the InsightTrack dashboard so traffic and bugs could be watched side-by-side. How We Built It To make this work seamlessly at scale (where one customer might poll 10 independent Sentry projects simultaneously), we built a dual-path ingestion system: The Polling Backstop: We set up a bounded worker pool (to prevent slow projects from stalling the fleet) that polls the Sentry API every 5 minutes. To respect rate limits, we built an adaptive cadence —active projects poll frequently, while quiet or erroring projects exponentially back off. The Near-Real-Time Webhook: For instant visibility, we allowed users to point a Sentry Internal Integration webhook at our API. Using HMAC signatures verified in constant time against a stored secret, new or regressed is

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration Egusi soup with pounded yam. Jollof gets the headlines, but egusi is the quiet one that actually holds Nigerian homes together. Melon seeds, ugu, palm oil, and a dome of pounded yam you eat with your hands. I already sent this challenge a love letter to jollof for the Perfect Landing prompt. This is the companion piece, and it targets a different audience: not a flat poster, but a photograph with real depth. The entire table sits in a single CSS perspective plane, so the bowl is genuinely a bowl. You look down into it. Demo A morsel of pounded yam is resting on top of the dome. Press "Dip the yam" and watch it lift off, cross the table, drop into the soup and come back stained. No JavaScript anywhere near it. Journey The rule I set myself: zero JavaScript. The one interactive moment runs on a checkbox and a sibling selector. The checkbox stays keyboard focusable, the label carries a visible focus ring, and if you've asked your system for reduced motion, the morsel skips the flight and just shows up stained. The whole scene is sized in container query units, so it scales as one object from a phone to a desktop without a single media query for layout. Some of the tricks I'm proud of: The table is one plane with transform-style: preserve-3d and a rotateX , so everything standing on it uses translateZ to mean "up off the table" The bowl is six rings flaring up the Z axis. The top two are masked hollow, otherwise, they paint straight over the soup, and the whole thing reads as a solid disc. That bug is what taught me the technique The soup sits below the rim on the Z axis, so you see the inner wall and the shadow it throws across the curds The pounded yam is six contours stacked into a dome, each one a little brighter as it climbs toward the light The egusi curds are eleven stacked radial gradients, the palm oil pools at the rim through an inset shadow, and the oil sheen is a blurre

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. ...

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration I chose to build a classic Dum Biryani — the ultimate comfort food! 🍛 There is nothing quite like opening a steaming handi of biryani and seeing the rich, saffron-colored rice dotted with fried onions, mint, and spices. It's a dish that brings people together and feels like a warm hug, making it the perfect inspiration for the Comfort Food challenge. Demo Here is my CSS Art representation of a traditional Biryani Handi! I built this primarily using vanilla CSS to create the realistic clay texture of the pot, the individual grains of rice, the steam animations, and the garnishes. I added a tiny bit of JavaScript just for a subtle mouse-parallax tilt effect and a saffron sparkle when you click the pot. https://github.com/pandeynitish23/dev_css_chalange/ https://dev-css-chalange.nitishkumar-nk-np.workers.dev/ Journey Building this was a really fun exercise in CSS gradients and positioning! What I'm most proud of: The Clay Handi: I used layered radial and linear gradients along with inset box shadows to give the pot a realistic, 3D clay texture with lighting highlights. The Rice & Garnishes: Creating individual rice grains, mint leaves, and onion crisps using CSS border-radius and positioning was tedious but incredibly rewarding when it all came together. The Atmosphere: Adding animated steam and floating background spice particles helped bring the scene to life and make it feel hot and fresh. It was a great challenge keeping the JavaScript minimal and relying on pure CSS for the heavy lifting of the art itself!

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing Mexico is our heritage. Yet, we have no family there to visit. That sounds sadder than it is. What it actually meant, for the years before my wife and I were married and most of our time off since, is that we had to go find it ourselves. No family kitchen waiting. No grandmother's recipe with an address attached. Just the two of us and a country that is ours and that we did not know. So we did what every hungry person in a new city does...we ate. Six cities, six completely different cuisines, and somewhere in there it stopped feeling like traveling. A tlayuda from a stand outside Santo Domingo in Oaxaca. An hour in line at El Yaqui with a michelada in Rosarito. Different food every time. Same feeling every time, and there is no English word for that feeling. There is a Spanish one. What I Built Sobremesa is the time you stay at the table after the food is gone, still talking. Not the meal. The part after the meal. That is the whole site. Six meals across six Mexican cities, and the thing it measures is not how good the food was. It is how long we stayed. Tijuana, one hour. Rosarito, two. Ensenada, one. Guadalajara, ninety minutes. Mexico City, two hours. Oaxaca, two. The page adds them up at the end. Nine hours and thirty minutes at six tables. Comfort food usually means a kitchen you can go back to. We do not have one over there. So the six tables became it. The stand at Plaza Santo Domingo is the family table. The hour in line at Tacos El Yaqui is the Sunday afternoon table. Each entry has the dish, where we ate it, one verified fact about the food, and one line that is just ours, from our experience. There is a form at the bottom where you add your own table and download a card of it, generated in your browser. Nothing gets sent anywhere. One static HTML file. No framework, no build step, no tracking, no cookies, no storage. Two fonts off Google Fonts and nothing else. Designed an

What I Built Gnoke Books works like an actual printed magazine on a table — you grab the...