标签：#dev

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

This is a submission for Weekend Challenge: Passion Edition ( https://dev.to/challenges/weekend-2026-07-09 ) What I Built Rivalry Radar — a live "Heat Index" for World Cup rivalries. Fans drop 280-character Terrace Takes on any matchup (Brazil vs Argentina, England vs France, whatever's got you shouting at the TV), rate how much the moment hurt or thrilled them from 1–10, and the app does the rest: Google AI (Gemini) scores every take's sentiment the instant it lands — positive, negative, mixed, or neutral — and separately writes a short "Hype Verdict" in the voice of a stadium announcer, based on the latest takes for a matchup. That sentiment score feeds a Heat Index, computed and ranked in Snowflake with RANK() OVER (ORDER BY heat_index DESC), combining take volume, sentiment intensity, and self-rated passion into one live number per rivalry. Two leaderboards: which rivalry is hottest right now, and which fanbase is bringing the most passion overall. Demo frontend/index.html is fully self-contained: opening it in a browser lets anyone submit takes, watch the Heat Index flip digit-by-digit like an airport departure board, and see the leaderboards re-rank in real time. It ships with seed takes from eight classic rivalries so it's not empty on first load. Code NandhuTee / Rivalry-Radar-World-Cup-passion-engine-with-Snowflake-Google-AI 🔥 Rivalry Radar — World Cup Passion Engine Fans drop 280-character Terrace Takes on any World Cup matchup. Google AI (Gemini) scores the emotion behind every word and writes a stadium-announcer Hype Verdict ; Snowflake stores every take and computes a live Heat Index that ranks exactly which rivalry is boiling hottest right now. Built for the DEV Weekend Challenge: Passion Edition 🏆 Best Use of Google AI and Best Use of Snowflake Why this exists Passion is easy to feel and hard to measure. Every World Cup rivalry generates an ocean of unstructured text — chants, rants, one-line hot takes — that traditionally just... disappears into grou

Hello Dev Community! 👋 It is officially Day 136 of my software engineering marathon! Today, I engineered the absolute heart of my MERN Stack capstone application, Sprintix : The complete Product Collection Grid & Faceted Filter Sidebar View ( /collection ) ! ⚛️🛍️🗂️ To prepare the application for seamless full-stack state management integration later, I built this layout using dynamic state arrays and object schemas. This ensures that switching from demo arrays to live API streams will happen effortlessly. 🛠️ Deconstructing the Day 136 Catalog Architecture As displayed across my browser rendering workspace in "Screenshot (311).jpg" and "Screenshot (312).jpg" , phase one of the product engine splits into structural layout segments: 1. Faceted Category Filter Sidebar Organized dedicated verification check-boxes mapping out specific consumer collections: Categories: Segmented target groups (Men, Women, Kids). Type Filters: Segmented style formats (Top Wear, Bottom Wear, Winter Wear). Styled within minimal box borders to give users an uncluttered desktop searching experience. 2. Header Control Grid & Sort Registries Installed a top-level workspace header showing "All Collection" alongside an interactive drop-down management node ( Sort by: relevant / low-to-high / high-to-low ). Ready to hold local state flags that rearrange the data arrays instantly before looping. 3. Deep Route Parameter Mapping Preparation Look at the hover elements in "Screenshot (311).jpg" ! Every single rendering card passes localized hex-token structures mapping toward dynamic pathways like: text /product/:id (e.g., /product/6a436b5c921b7aa010d29318)

Hey DEV community! 👋 Like a lot of you, I had a mental list of "quick tool" bookmarks scattered everywhere — a word counter here, a slug generator there, a Lorem Ipsum generator somewhere else. I got tired of it, so I built Yanapex: a single site with free, no-signup tools for text, images, and everyday dev tasks. A few things I focused on: Everything runs client-side. No text or files get uploaded to a server, so it's safe to paste sensitive drafts or code. No accounts, no paywalls. Open a tool and use it immediately. Fast and lightweight, built for quick one-off tasks instead of full blown apps. One of the first tools is a Word Counter ( https://yanapex.com/en/tools/text-tools/word-counter/ ) with real-time word/character/sentence counts and reading time estimates. There are 26 tools so far across text, image, and developer utilities. Would love feedback from this community: what's a small tool you constantly have to search for online that you wish just existed in one place?

This is a submission for Weekend Challenge: Passion Edition What I Built I have lots public repositories. some of them are dead. Not deleted — dead. There's a difference. Deleted would mean I made a decision. Dead means one day I committed "fix readme typo" and never came back, and the repo has been lying there ever since, full of half-finished dreams and a TODO.md I'm afraid to open. Everyone builds graveyards for these projects. Post-mortems. Eulogies. I didn't want a graveyard — because my projects aren't dead to me. They're comatose . So I built the other room in the hospital. LIFE SUPPORT is an intensive care unit for your side projects. You admit your GitHub username to the ward. Every repo becomes a patient on a live, animated EKG monitor — commit cadence is the heart rate, and projects you've abandoned show the one thing no developer is emotionally prepared to see: A flatline. With the sound. Then the lab runs your entire commit history through Snowflake and prints your chart, including the number I was genuinely afraid to learn about myself: My passion half-life: [23] days. The median time it takes my enthusiasm for a new project to decay by 50%. Fitted as an exponential decay curve over my actual weekly commit counts. My love has a measurable half-life, and it is shorter than a gym membership. The chart also includes: BPM — beats per month. One commit, one heartbeat. The 2 AM index — [26]% of my commits happen between midnight and 5 AM. That is not a schedule. That is love. Ward census — [3] alive, [6] flatlined, [1] critical. Longest flatline — [ crypto-tracker ], silent for [2.2 years], built at the exact top of the market. And then — the part I'm proudest of — the app doesn't let you just feel bad . Every flatlined patient has a red button: ⚡ DEFIBRILLATE Pressing it opens a revival pledge on Solana : a memo transaction, signed with your own wallet, containing a vow to ship at least one commit to that repo within 7 days. It's permanent, timestamped, and

Hello Dev Community! 👋 It is officially Day 134 of my software engineering marathon! Today, I successfully extended the layout grids of my MERN Stack capstone e-commerce application, Sprintix , by implementing fully responsive feature banners, newsletter hooks, and a clean global footer! ⚛️🛡️📬 A premium storefront relies heavily on trust anchors and consistent site-wide navigational structures. Today's focus was ensuring these terminal layers look flawless across all viewport breaking thresholds. 🛠️ Deconstructing the Day 134 Interface Terminal As captured in my local hosting environments within "Screenshot (301).jpg" and "Screenshot (302).jpg" , the system layout introduces high-fidelity structural blocks: 1. Trust Policy Infrastructure Positioned a 3-column micro-service layer layout framing crucial customer success policies (Easy Exchange, 7 Days Return, 24/7 Support). Balanced standard tracking font sizes and vector alignments to maintain optimal layout readability. 2. Immersive Newsletter Conversion Segment Engineered an engaging email onboarding banner using rich layered visual configurations. Integrated a responsive inline input element paired with an absolute action button to ensure the container shifts scales perfectly when transitioning down to mobile form factors. 3. Consolidated Multi-Grid Footer System Look at "Screenshot (302).jpg" ! Structured a highly scalable flex-wrapping matrix containing: Brand Identity Columns hosting contextual descriptive descriptions. Navigational Routing Indexes pointing clearly to operational views (Home, About Us, Privacy Policy). Direct Touchpoints aggregating structural contact details. Finished off the grid matrix with a clean full-width divider row holding structural copyright information. 💡 The Technical Win: Designing for Fluid Responsiveness First When building high-traffic online stores, mobile responsiveness isn't a secondary polish step—it has to be native. Writing components with flexible flexbox wrapping, relat

I recently found an old project I built with a friend around 2017–2018: a perk calculator for the game Firefall. The application allowed players to browse perks by category, drag them into a build, track the available perk points and automatically filter incompatible options based on the selected class. Looking at the code today, there are many things I would structure differently. The JavaScript could be better organised, responsibilities could be clearer, and the overall architecture would benefit from more modern practices. Still, I decided to preserve it as it is. Older projects are useful reminders that progress is not only visible in the technologies we use, but also in how we model problems, organise code and make technical decisions. It is not a showcase of how I would build the same application today. It is a snapshot of how I approached a real problem at that point in my career. Repository: https://github.com/lksvn/firefall-perk-calculator

A hands-on comparison where I tested BrowserAct and Agent Browser using the SannySoft browser...

This is a submission for Weekend Challenge: Passion Edition . During the World Cup , millions of people can watch the same match. But every stadium tries to say something different before kickoff. Sometimes it is belief. Sometimes defiance. Sometimes memory. Sometimes unity. I follow football closely, and some of the moments I remember most are not goals. They are the few seconds before kickoff when the camera pulls wide and an entire stand reveals one message at once. That was the idea behind Tifo Forge . It is an interactive experience that turns a team, a supporter emotion, and a symbol into an animated stadium tifo. Not another match tracker. Not another football chatbot. Tifo Forge turns supporter emotion into a stadium moment. What I Built Tifo Forge asks the user to make three choices: A national team A supporter emotion A visual symbol The emotions are simple on purpose: Believe Defy Unite Remember The symbols include ideas such as lightning, a phoenix, wings, a heart, and dawn. Once those choices are made, Gemini creates a structured design plan. The browser then turns that plan into an animated stadium display. I deliberately avoided uploads, accounts, and long setup screens. I wanted someone to open the page and reach the reveal in under a minute. Three choices are enough to raise the stand. The final result can be replayed, reset, or saved as an SVG poster. Demo Try Tifo Forge: https://tifo-forge.vercel.app/ I kept thinking about those few seconds before kickoff when everyone in the stadium knows something is about to happen, but nobody has seen the full picture yet. That became the interaction: Choose the team ↓ Choose the feeling ↓ Choose the symbol ↓ Raise the tifo When the user clicks Raise the Tifo , the stadium darkens. Rows of cards flip into place. The pattern spreads across the curved stand. The central symbol appears, and the chant locks into position. The user is not asking for a random poster. They are deciding what the stand believes, how it

This is a submission for Weekend Challenge: Passion Edition What I Built Hi! My name is Dave and my background is webmaster/front-end web developer. I have long been curious about creating desktop apps, and I figured this was the perfect opportunity to build one. I also am a novice player of contract bridge, also known as just "bridge", so I figured I would make a bridge app since I am passionate about it. In bridge, many people like to do a double dummy simulation where all 52 cards are visible between the four positions (North, South, East, and West). This allows them to see how many tricks are possible with a given contract and deal. This allows them to improve their declarer (offensive) play as well as their defensive play and improves analytical decision-making. It also allows them to perform an effective post-mortem analysis (i.e., what went wrong). Since this is a weekend challenge, I didn't get the chance to add some more functionality like I wanted. In addition to improving the UI, I'd also like to actually be able to play through different hands and add a scoring mechanism that you see on bridge score calculators online. I think combining that with a way to play full hands would be where I would want to go from here. Demo Code DaveH1981 / double-dummy-bridge-calculator An app for contract bridge players that uses the double dummy method to find the best card play sequence. double-dummy-bridge-calculator An app for contract bridge players that uses the double dummy method to find the best card play sequence. Front end, C++ wrappers, and engine callers are mine. This app connects to the DDS bridge solver written by Bo Haglund, Soren Hein, and Martin Nygren. They reserve all rights as per the Apache 2.0 license. View on GitHub How I Built It My background is mostly front end, so that was pretty straightforward for me. The most difficult part was figuring out how to link to the DDS double dummy bridge engine. I went with Electron and GYP as a wrapper, linking

Last month, an AI coding agent handed me a beautiful fix. Five lines. Elegant. It reused an existing helper, matched the codebase style, compiled on the first try. Exactly the kind of diff we've all learned to praise since "make the agent write less code" became the standard advice. It was also completely untested, and it sat on a password-recovery path. That diff taught me something I now consider the central problem of AI-assisted coding in 2026: we've spent a year teaching agents to write less code, and almost no time teaching them to prove the code they kept actually holds. The two failure modes Every AI coding agent fails in one of two directions. Failure mode #1: the over-build. You ask for a date comparison; you get a new dependency, a ValidationService class, and a config layer. This one is well known — it's why minimal-code prompts and skills became popular, and they genuinely work on it. Failure mode #2: the confidently small diff. Minimal, clean, written after reading half the flow, verified never — dropped onto a path that handles money, auth, or user data. It compiles. It demos. It detonates in week three. Here's the uncomfortable part: fixing #1 aggressively makes #2 more likely. When the objective function is "shortest diff," the first things to quietly disappear are edge-case handling, failure-path tests, and the guard clause that looked optional. The diff gets smaller. The blast radius doesn't. A five-line change to a payment path is more dangerous than a four-hundred-line internal script that runs once. Code size is not risk. Blast radius is risk. Yet almost every skill and prompt in this category optimizes for size alone. What a guard does differently This is why I built Guardsman 💂 — an open-source skill that behaves less like a minimalist and more like the royal guard in front of the palace: nothing passes the post unchallenged, and the level of challenge depends on what's behind the gate. Three duties, on every task: 1. Read the standing orders

This is a submission for Weekend Challenge: Passion Edition What I Built Passion Roast is an AI "Passion Judge" that looks at a photo of your fan setup, collection, or hobby corner — plus the name of whatever you're obsessed with — and roasts you for it, scores your devotion out of 100, and hands you a mock diploma for your dedication. The goal was simple: capture the universal feeling of being a little too into something you love, and let an AI genuinely react to real, specific details in your photo instead of giving generic responses. Demo 🔗 Live app: https://passion-roast-production.up.railway.app 🎥 Demo video / GIF: <link here> Try it with a photo of anything you're passionate about — a jersey collection, a gaming setup, houseplants, vinyl records, whatever. Each roast is generated fresh from what's actually in the picture. Code https://github.com/NOVA-X-Code/passion-roast How I Built It Backend: Node.js + Express, with Multer handling in-memory image uploads (no files ever touch disk). Google AI (Gemini API): the entire app is built around a single multimodal call — the uploaded photo (as inlineData ) and the declared passion are sent together to Gemini with a system prompt defining "The Passion Judge" persona. Gemini is instructed to return strict JSON (passion score, mock diploma title, roast, verdict), which the backend parses and validates before sending it to the frontend. Frontend: vanilla HTML/CSS/JS with drag-and-drop upload and a shareable-style result card — no frameworks, no build step. I deliberately kept the stack to a single external API. Rather than chaining multiple services, I focused on getting real value out of Gemini's multimodal reasoning: the roast has to reference actual details Gemini sees in the image, not just repeat the passion name back with generic flattery/insults. Prize Categories Best Use of Google AI weekendchallenge

Interactive Rive mascots can react, think, talk, and connect to real AI, SaaS, web, and mobile products. Your SaaS Mascot Should Do More Than Just Sit There 👀 A lot of products have mascots. They look great on landing pages. Maybe they wave. Maybe they blink. Maybe there is a small looping animation. And that's it. But I think a product mascot can do much more. What if your mascot actually knew what was happening inside your product? That's the idea I've been exploring with Mascot Engine . I don't just want to animate characters. I want to build interactive mascot systems that connect to real products . From a mascot animation to a product system Imagine you're building an AI app. A user opens the app. The mascot is idle . The user sends a message. The mascot starts thinking . The AI begins responding. The mascot switches to talking . The task completes. The mascot celebrates . Something goes wrong? The mascot reacts to the error . The flow could look like this: User Action ↓ Product State ↓ Runtime Input ↓ Rive State Machine ↓ Mascot Reaction This isn't a video. It isn't a GIF. It isn't a pre-rendered animation playing randomly. The product controls the mascot at runtime. That's where things become interesting. A mascot can understand product states Well... not literally understand them 😄 The application still owns the logic. But we can expose a small runtime contract from the Rive file. For example: emotion = 2 isTalking = true lookX = 40 lookY = -10 celebrate = trigger error = false The developer controls these values from the application. The Rive State Machine handles the character behavior. The application controls what happened . The mascot system controls how the character reacts . I really like this separation. Why I use Rive for interactive mascots Traditional animation tools are great for videos and motion design. But product animation has different requirements. The character needs to react to application events. The animation may need runtime values. De

This is a submission for Weekend Challenge: Passion Edition What I Built HahaNotes is an interactive web application designed to help developers, office workers, and students vent their daily stress by transforming real-world struggles (legacy code at 3 AM, unpaid overtime, sếp hãm, or exam stress) into hilarious, sarcastic AI-voiced banters, complete podcasts, and ready-to-share short videos. The application features a dynamic dialogue between two contrasting AI hosts: Rookie (The Naive Optimist): A starry-eyed beginner who sees the world through rose-colored glasses and speaks in trendy buzzwords. Cynic (The Sarcastic Senior): A battle-hardened veteran who gently (or not so gently) pops Rookie's bubble with witty, dry, and highly relatable tech sarcasm. Users can input their struggles, choose their favorite voices for the hosts, generate structured comedy scripts, chat continuously with the hosts to extend the banter, listen to fully produced podcasts with ambient lo-fi background music/laugh tracks, and export 9:16 vertical short videos with synchronized karaoke captions and visual memes. Demo Video Demo: Website Demo: https://hahanotes.vercel.app/ Code omlttg / hahanotes 🎙️ HahaNotes Banishing Developer Burnout with AI Banter Podcasts & Short Videos Live Demo: hahanotes.vercel.app Weekend Challenge: Submitted for Weekend Challenge: Passion Edition 🌟 Introduction HahaNotes is an interactive web application designed to help developers, office workers, and students vent their daily stress by transforming real-world struggles (e.g. legacy bugs at 3 AM, unpaid overtime, or exam anxiety) into hilarious, sarcastic AI-voiced banters, complete podcasts, and ready-to-share short videos. The application features a dialogue between two contrasting AI hosts: Rookie (The Naive Optimist): A starry-eyed beginner who sees the world through rose-colored glasses, uses corporate buzzwords, and believes completely in hustle culture. Cynic (The Sarcastic Senior): A battle-hardened ve

This is a submission for Weekend Challenge: Passion Edition What I Built I built Origin —...

Python is an excellent language for automating cloud infrastructure, but the official Kubernetes Python client leaves developers with an important architectural decision: Where should Kubernetes manifests live? Should they be constructed directly with Python objects? Embedded as multiline strings? Or stored as external files and rendered at runtime? Each approach works, but they have very different implications for readability, maintainability, and long-term operational cost. The key is recognizing that deployment logic and platform configuration evolve on different lifecycles. Your deployment code, the part that authenticates to Kubernetes, renders templates, and applies resources, may remain unchanged for months. Your manifests, however, often change weekly as applications evolve, resource limits are tuned, cloud-provider annotations are added, or networking requirements change. When those two concerns are tightly coupled, even a configuration, only change forces you to modify, test, and redeploy the delivery or application code itself. Over time, this increases maintenance costs, slows platform changes, and makes configuration drift and production mistakes more likely. This is a familiar software engineering principle: separate concerns that evolve independently. The same thinking that keeps application configuration separate from executable code also applies to Kubernetes manifests. Treating manifests as first-class configuration artifacts allows them to evolve independently from the Python code that delivers them. In this article we'll compare three ways of deploying Kubernetes resources with the official kubernetes-python-client , ranging from tightly coupled implementations to a design that cleanly separates deployment logic from platform configuration. The Landscape at a Glance The comparison below assumes a common application deployment scenario, where the desired state is largely known ahead of time. Controllers and Operators have fundamentally different r

Hi guys, I've been working on Regdrift, my first open-source project. It's a CLI and GitHub Action that compares two CMSIS-SVD files to check whether there are any register-map changes that could affect firmware functionality. It catches changes such as moved registers, interrupt renumbering, access changes, and altered read/write behavior. It then classifies those changes as BREAKING , WARNING , or SAFE so the tool can act as a CI gate. I'm looking for feedback from people who maintain SVDs, HALs, PACs, SDKs, or firmware repositories. If possible, I'd like to test it against real old/new SVD pairs and learn where the classifications produce false positives, miss important changes, or are unclear. For people who work frequently with CMSIS-SVD files: which types of register-map changes are most detrimental to firmware or cause the most difficult code-related problems? Resources GitHub: https://github.com/Pranav-s79/regdrift Install pip install regdrift Usage regdrift check old.svd new.svd

This is a submission for [Weekend Challenge: Passion Edition] What I Built Over the years, I watched my mom do the same work over and over, often spending 2 to 4 hours preparing a single telecom SLA report. She works in network field maintenance for a telecom company in Nigeria, and every reporting cycle she has to manually read fault descriptions from field engineers, usually pasted directly from WhatsApp, classify each fault into the company's standardized taxonomy, and format everything into an Excel compliance report. At one point, I learned the process myself so I could truly understand what she was going through. After doing it firsthand, I realized how mentally and physically exhausting it was. Sitting for hours on a repetitive task that required constant attention wasn't just inefficient, it was draining. That experience made me ask one simple question: What could I build to make this easier for her? That question became this project. The Telecom RCA Automation System reduces a task that used to take 2 to 4 hours to about 5 minutes, cutting the workload by more than 95% while improving consistency and reducing manual errors. This project wasn't built over a single weekend. It started months ago as a side project that I'd return to whenever I had free time. It never quite felt ready to share. When the Weekend Challenge: Passion Edition was announced, it gave me the motivation to go back, refine the classification engine, fix long-standing bugs, improve the user experience, and finally build something I was proud to release. More than anything else, this project is about giving someone I love a few hours of her evening back. Demo https://telecom-rca-automation-system.vercel.app * 🎥 Demo Walkthrough * https://youtu.be/EIdFDKtcIZw The video demonstrates the complete workflow, from uploading the telecom availability report to generating the final SLA report, and highlights how Google Gemini AI assists with ambiguous fault classification. Code https://github.com/t

Here is a design decision we made early, wrote into the architecture as an invariant, and have refused to revisit since: our agent accepts no commands. Not "we don't currently use that feature" — the hub has no way to tell an installed agent to do anything at all. No remote execution, no self-update, no "collect this for us right now". It sends data outward, and that is the entire surface. This is not a limitation we are working around. It is the product. And it costs us features that customers ask for, which is exactly why it is worth explaining. The uncomfortable arithmetic of remote control Any tool that can update a plugin across fifty client sites is, by construction, a tool that can execute code on fifty client sites. Any dashboard that can restart a service on your server holds, somewhere, a credential that lets it in. This is not a flaw in those products — it is what they are for. You cannot automate a repair without the power to perform it. But that power has an owner, and the owner has a login, and the login has a support team, and somewhere in that chain there is a version of the software with a bug in it. When the tool is compromised, the blast radius is not the tool. It is every machine the tool could reach. The industry has already run this experiment at scale. In July 2021, attackers exploited a vulnerability in a widely used remote monitoring and management platform. They did not break into a single company — they broke into the thing that had access to the companies. Roughly sixty managed service providers were hit, and through them, an estimated 800 to 1,500 downstream businesses were encrypted in a single weekend, with a $70 million ransom demand attached. Read that shape again, because it is the whole argument: the victims did nothing wrong. They had bought a well-known product from a serious vendor and installed it exactly as instructed. Their compromise arrived through the door they had deliberately, sensibly, contractually left open — the one

Concept design for a building is slow and expensive. A homeowner planning an extension, or a contractor trying to win a job, is stuck between two bad options: pay a drafter $500–2,000 for a concept package, or fight SketchUp's learning curve for a week. Meanwhile the actual idea — "a 4-bed duplex with a garage and a palm out front" — fits in one sentence. So I built Forge3D Spaces : you type that sentence, and a few seconds later you're walking through a furnished 3D house in your browser — with measured floor plans, DXF for AutoCAD, and a cost estimate that come out of the same model. No install. Here's how it works under the hood. The pipeline: sentence → structured plan → building The naive approach — "ask an LLM to emit a 3D scene" — falls apart fast. Models are bad at spatial consistency; walls don't meet, rooms overlap, doors float. So the LLM never touches geometry directly. It emits a structured program , and a deterministic solver turns that into a watertight building. The prompt becomes a spec. A strict JSON-schema call (OpenRouter, json_schema response format with every field required) turns "4-bed duplex with a garage" into a room program: room types, target areas, adjacencies, storeys. A slicing-tree solver lays it out. This is the old floorplanning trick from chip design — recursively split a rectangle with horizontal/vertical cuts until every room has its area. A squarify pass keeps rooms from collapsing into corridors. The output is exact rectangles with real dimensions, guaranteed non-overlapping and gap-free. Walls, openings, roof, furniture get generated from the solved plan. Every door and window is placed by rule, not by vibes. Because the plan is a real data structure, the 2D floor plan, the 3D model, the elevations, and the bill of quantities are all views of the same thing . Drag a wall and they all move together. Nothing drifts out of sync, because there's nothing to sync — it's one model. The rendering: WebGPU, and the fallback you actually