标签：#snowflake

This is a submission for Weekend Challenge: Dog Days Edition Dog Whisperer is an app that looks at a photo of your dog, figures out what it's probably feeling, and then actually says it out loud in a voice that matches the mood. Grumpy dog gets a grumpy voice. Dramatically offended dog gets... a dramatically offended voice. You get the idea. It also doubles as a pet log — meals, weight, and walks tracked over time in Snowflake, with trend charts so you can actually see if your dog's been eating more than usual or losing weight. Add your pets and start logging. Use your unique username to keep track of your pets! Here is App in action: https://dogwhisperer-whi6rye8zklcdtnedyxmww.streamlit.app/ Demo Code Kaku-g / dog_whisperer How I Built It I used Google's Gemini (model: gemini-3.5-flash-lite ) to infer the mood of the dog (or cat, lizard, ferret — whoever's in the photo) from a single image, then passed that straight into Gemini's native TTS (model: gemini-3.1-flash-tts-preview ) to give it a voice that actually matches the mood — a sleepy dog sounds sleepy, a dramatic one sounds dramatic. For logging and trends, I used Snowflake — compute, databases, and tables — to store meals, weight, and walks for every pet and power the trend charts in the app. So it's really two things working hand in hand: a generative AI pipeline paired with a data warehouse. The AI part is what makes the app fun — inferring your pet's mood and giving it a voice. The Snowflake part is what gives it a real use case , since it's something you could keep using for long. Prize Categories I used Google AI and Snowflake, so I'm submitting under both: 🏆 Best Use of Google AI 🏆 Best Use of Snowflake

This is a submission for Weekend Challenge: Dog Days Edition Target categories: Best use of Snowflake + Best use of Solana. Ten days from now International Dog Day is August 26th. The date is not arbitrary and it is not a marketing pick. Colleen Paige founded it in 2004 and chose the 26th because that is the day her family brought her first dog home from a shelter , when she was ten years old. So the holiday is not really about dogs. It is about the gap between a dog sitting in a shelter and a dog sitting in a house, and about how many animals never cross it. That gap is the whole reason this project exists, and it is why the last tab of this dashboard is the quietest one. I did not start at the shelter. I started at a limp nobody saw. But every path I traced ran the same direction, and it always ended in the same room. This is a build post, so most of what follows is SQL. But I want to be honest about which end of the problem I was standing at when I wrote it. The problem, stated plainly Because a hackathon post should be able to say this in four rows before it earns the right to show you any SQL: The question In one line The issue A dog in pain is built to hide it, so the first human-readable sign of a chronic problem arrives months late - often at the point the relationship, not just the joint, has broken down. Why software has not fixed it Every consumer tracker compresses a day of movement into a scalar - steps, active minutes, a sleep score - and then thresholds it. The clinical signal is not in the magnitude. It is in the ordering , and averaging is precisely the operation that deletes ordering. What TELLTAIL tries Stop thresholding. Make the detector a regular expression over rows - MATCH_RECOGNIZE - so a differential diagnosis stays a sequence all the way down to the individual second that satisfied it. How you know it is not a demo Every finding is explainable to the second, the accuracy is printed in 44px type on the dashboard including the parts that are

This is a submission for Weekend Challenge: Passion Edition What I Built Rivalry Engine — pick two national football teams, and Snowflake reads 150 years of their matches, scores how heated the rivalry is, calls a one-word verdict on its shape, predicts the next result, and lets Cortex narrate the one story inside it. All of it — the data, the analytics, the AI, and the app — runs inside Snowflake. Nothing ever leaves the warehouse. A scoreboard tells you who won. It never tells you what the rivalry means . Argentina and Brazil have met over a hundred times across a century — a razor-thin ledger that has never let either side feel safe. Germany and England meet rarely, but every meeting carries a tournament's weight. Most national teams have never played each other at all. My goal was a product that could feel the difference between those three shapes — not another stats table, because a table is a report and I wanted an argument. The passion is football. But the real engineering question underneath it was the one I actually cared about: can an AI tell the story of a rivalry without lying about the facts? So I gave myself one rule before writing a line of code: The AI interprets the shape of a rivalry. It never invents the facts. Every count, date, score and streak on screen is computed in SQL from real matches. Cortex is handed only those computed facts, and told explicitly to never produce a number. And its honest corollary: two nations that never met get a "first chapter unwritten" card — and Cortex is never called. A product that can't return nothing will invent something. This one returns nothing. Demo It runs entirely in Streamlit in Snowflake (Snowsight) — no public host, no API keys — so here's a walkthrough: The 90-second tour: Argentina vs Brazil → the heat gauge pins to 🔥 Blood rivalry , recent-form chips light up, and the SQL detector's verdict reads Blood feud . ✨ Generate the story → Cortex writes a narrative that cites the real biggest thrashing and f

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

This is a submission for Weekend Challenge: Passion Edition TL;DR SQL can count a commit trail. It can't always find the story it tells. Name a public GitHub repo. Snowflake fetches its commit history, decides which story is actually in there, and asks Cortex to narrate that one thread. You get a card you can drop into a README. 6 storyline detectors, 15 SQL views, and 0 AI calls in any of them—the story is chosen by plain SQL. Then 1 Cortex call, on 20–140 commit lines: 25% of the repo's, clamped. The warehouse is the editor. Cloud Run paints a PNG and computes nothing. Live at commitchronicles.anchildress1.dev , code at v1.0.0 , and I'm going for Best Use of Snowflake . What I Built Commit Chronicles reads one public GitHub repo and gives it back to you as a story. Snowflake fetches the repository, decides which story exists, gathers the evidence, asks Cortex to narrate exactly that thread, validates the result, and returns structured JSON. Cloud Run just turns it into a 1200×630 PNG—the size a README embed and a social preview both want. This is one of my repos and every dot, timestamp, and quoted commit on it is real. The color isn't just decoration—Cortex picks the accent hex as a reading of the arc, so a repo that died and one that came back and shipped don't look the same. The scope is deliberately one repository , not a whole profile. A year-in-review across a profile turns to mush. A repo has a clean arc: commits start, cluster, pause, restart, or stop. Two rules hold it together: Cortex interprets the shape. It never invents the facts. Every timestamp, count, gap, and quoted message on the card is real. It reads the arc; it does not reach past it. Motivation isn't in the data, so the model is forbidden from claiming any. A repo with no real story says so. Sparse histories get an honest grey card— "no story here" —and Cortex never runs. Not every repo is an obsession, and a tool that admits that is the one you trust when it says otherwise. Why I built it 🪤

This is a submission for Weekend Challenge: Passion Edition Target categories: Best use of Snowflake...

From Optimization to Protection: Adding a Security and Governance Agent to Your Snowflake Multi-Agent Team (Part 3) In Part 1 , we built an Admin Agent for usage and cost visibility. In Part 2 , we added a Cost Optimizer Agent and an Orchestrator that routes questions to specialists. Now we close the loop with the third specialist: a Security and Governance Agent . This turns your assistant from "what happened" and "what to optimize" into a full team that also answers "what is risky right now". By the end of this post, you will have: A Security and Governance Agent with focused security tools Security semantic views mapped to natural language Orchestrator routing across Admin, Cost Optimizer, and Security agents A practical triage workflow for failed logins, privilege risk, and unauthorized access Why Add a Security Specialist? The first two agents are strong for operations and spend, but security requires a different lens: Access control and role hygiene Failed login patterns and anomaly detection Unauthorized access attempts Inactive users with active privileges Compliance-friendly audit summaries Could one large agent do everything? Sometimes. But specialized agents are easier to maintain, safer to evolve, and easier to test. Final Team Architecture User Question (natural language) | Orchestrator Agent / | \ Admin Cost Security Agent Optimizer Governance Agent \ | / Unified Response Role of each specialist Admin Agent: usage, credits, storage, operational metrics Cost Optimizer Agent: idle compute, rightsizing, optimization opportunities Security and Governance Agent: roles, privileges, failed logins, unauthorized access, audits The Security Pattern (Same Foundation as Parts 1 and 2) Step 1: Base Views Create security-focused views over SNOWFLAKE.ACCOUNT_USAGE , including: Role hierarchy and privilege grants Failed login attempts and anomaly severity Excessive or unused privileged access Unauthorized access attempts User and role audit summaries Network policy ac