DEV Community: Sourav

My Grandpa Measures in Handfuls: Turning His Voice Memos Into a Family Recipe Book

Sourav — Mon, 05 Oct 2026 06:59:40 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend (https://dev.to/challenges/hacktoberfest-weekend-2026-10-01).
What I Built

Garp turns my grandpa Thatha's voice memos into a family recipe book. He talks, the app listens, and a 3D book page appears with the recipe written the way he actually said it.
The problem is simple. Thatha is getting older and his recipes live nowhere except his head and a pile of phone voice notes. When he says "a handful of dal" or "don't rush the onions, they'll punish you," no normal recipe app knows what to do with that. Write it down wrong and the dish dies with him.
So I built him a book that accepts voice memos and live recordings, figures out whether the note is actually a recipe, and refuses anything that isn't. A story about the neighbor's dog never lands in the book. A dal memo becomes a Dal page, ingredients first, numbered steps after, his tip quoted at the bottom, signed Grandpa.

Demo
There is no public link yet. It runs on my machine with two commands:
PORT=8001 python3 -m extractor.server
then open http://127.0.0.1:8001. The homepage is the 3D book. Click "Add a voice or live memo," pick Voice to upload a file or Live to record in the browser. A real memo I recorded came back as the Dal page: five ingredients, six steps, 2970 STT credits spent, one tinker call. Non-recipe audio gets a plain "Not added" message and nothing is saved.
Repo: https://github.com/LusterSourav/Garp

Code
The whole server is Python stdlib, no framework. The pipeline is one file per job: memo_ingest.py guards the upload, transcribe.py turns speech into text, extract.py turns text into recipe JSON, to_nyum.py writes the book file, bookview.py renders the 3D pages. test_smoke.py keeps it honest offline.

https://github.com/LusterSourav/Garp

How I Built It
The open pieces are the core, not decoration.
Transcription tries local first. If faster-whisper is installed, the memo never leaves the laptop: the transcript gets scored on word count, confidence, no-speech probability, and repetition loops, and only a clean transcript is accepted. If local fails or nothing is installed, the same saved temp file goes to ElevenLabs Scribe automatically. The user never re-uploads. Credits burn only when the cloud actually runs.

Extraction has a local path too through Ollama and Qwen, with Backboard's Claude Haiku as the hosted fallback. The prompt is strict: speaker's own words for quantities, never invent, vague things go in unclear, non-food returns empty and gets rejected with a 422. The recipe is written in whatever language Thatha spoke.
The book itself is vendored everything: Barlow and Lora fonts, Tabler icons redrawn on canvas with rough.js, no CDN. Long recipes paginate inside the 3D page and turn with a curl animation, no buttons, just tap left or right.

Why Does Open Innovation Matter?
Because this book cannot depend on anyone's server but ours. Faster-whisper means Thatha's voice can stay on a laptop in his house. Qwen through Ollama means extraction works with no account and no bill. MIT-licensed templates and icons mean the whole thing is mine to keep, fork, and hand to my cousins without asking permission.
A closed API could do each step. It could never give me this: a gift I can copy onto a ten-year-old laptop, run offline at his kitchen table, and know it will still work when the free credits are long gone. Open made it a family heirloom instead of a subscription.

Prize Categories
Entering for the overall prize only.

Day 1 to understand Floresta

Sourav — Sat, 04 Jul 2026 13:40:22 +0000

Ballerina vs Node.js: Building Modern APIs (Plus macOS Setup Tips)

Sourav — Sun, 12 Oct 2025 04:39:08 +0000

In API development, two names often come up: Ballerina and Node.js.
Both are powerful — but they take very different paths. Here’s a quick technical breakdown

Language and Design

Ballerina is a cloud-native language built for network services. It has an HTTP listener and service construct baked in, making APIs feel declarative. It’s statically typed, helping catch issues early.
Node.js is a JavaScript runtime (V8 engine) — dynamic, flexible, and usually paired with frameworks like Express.
➡️ Ballerina focuses on integration and reliability.
➡️ Node.js focuses on speed and flexibility.

Ecosystem and Libraries

Node.js wins in ecosystem size — npm offers thousands of packages and frameworks (Express, NestJS, Fastify).
Ballerina offers built-in connectors for HTTP, gRPC, Kafka, databases, etc., so many integrations need no third-party code.
Ballerina’s “inbuilt networking primitives” make service composition simple — ideal for enterprise APIs.

Performance and Concurrency

Both handle non-blocking I/O well but differ in approach:
Node.js uses a single-threaded event loop, perfect for real-time apps.
Ballerina uses lightweight strands, offering high concurrency and performance for microservices and data-heavy workloads.

Use Cases

Ballerina → Great for enterprise-grade APIs, observability, OpenAPI generation, and Kubernetes/Docker deployment.

Node.js → Perfect for fast prototyping, real-time systems, and startups that thrive on JavaScript speed.

Summary

No one-size-fits-all winner:
Choose Ballerina for strongly typed, integration-heavy systems.
Choose Node.js for rapid builds and ecosystem power.
Often, both coexist — Ballerina for backend microservices, Node.js for gateways.

Bonus: Ballerina Setup Tips for macOS

Common fixes if setup fails:
Use Java 17+ (older versions cause compiler errors).
Install via brew install bal or .pkg.
For M1/M2 Macs, use Swan Lake 2201.5.0+.
Run bal version to verify install.
Fix JAVA_HOME if VS Code plugin fails.
Once configured, Ballerina runs smoothly on macOS — ready for your next API build!

💡 Conclusion:

Ballerina’s integration-first, cloud-native design complements Node.js’s speed and ecosystem perfectly. Both have their place in the modern API stack.

Ballerina #Hacktoberfest #OpenSource #API #NodeJS #SoftwareEngineering #Integration #CloudNative #BallerinaLang @BallerinaLang

No Dependencies, Just Adventure: Introducing Mystic-Quest in Python

Sourav — Sun, 22 Jun 2025 15:04:43 +0000

Discover Mystic-Quest, a beautiful retro-inspired text-based adventure game built entirely in Python 3 with no external dependencies. Dive into a world of ASCII art, challenging riddles, magical encounters, and hidden treasures. With 10+ unique endings shaped by your choices, Mystic-Quest offers a nostalgic yet fresh experience for fans of interactive fiction and classic games. In this post, I’ll walk you through the game’s features, design choices, and how you can play or contribute!

Why I Chose to Create a Text Adventure?

Text adventure games hold a special place in gaming history—they ignite imagination, encourage problem-solving, and let players become part of the story in a unique, interactive way. I wanted to capture that nostalgic magic while making it accessible to everyone with simple Python 3, no dependencies, and fun ASCII art. Developing a text adventure also allowed me to focus on creative storytelling, riddles, and multiple endings, rather than complex graphics or external libraries. It’s both a tribute to classic games and an invitation for new players (or coders!) to experience the joy of interactive fiction.

Game Story Idea

Mystic-Quest is set in a mysterious, enchanted realm where the player awakens with no memory, surrounded by ancient ruins and cryptic symbols. As you explore, you encounter magical beings, solve riddles, and make choices that shape your destiny. The world is filled with hidden treasure chambers, ancient secrets, and mystical artifacts. Each decision you make—whether to trust a mischievous spirit, open a forbidden door, or solve a puzzle—leads to a unique storyline and one of 10+ possible endings. The game combines classic adventure elements with original riddles and interactive storytelling, encouraging replayability and imagination.

How Q Helped Me Generate and Debug Code...hm???

Q, as an AI-powered coding assistant, was invaluable throughout the development of Mystic-Quest. Here’s how it helped:

Rapid Prototyping: Q helped me quickly generate Python code snippets for handling user input, branching storylines, and rendering ASCII art, saving me hours of manual coding.
Debugging Assistance: Whenever I encountered errors—like logic bugs in riddle checks or unexpected crashes in story branches—Q analyzed the stack traces, suggested fixes, and explained the root causes in clear language.
Refactoring and Best Practices: Q offered suggestions to improve code readability and structure, such as breaking large functions into smaller ones or using more descriptive variable names.
Creative Ideas: When I needed inspiration for new story twists or riddle formats, I could brainstorm with Q to add more depth and replayability to the game.
Documentation: Q helped me document functions and provide clear instructions for players and contributors.
Overall, Q streamlined the coding process, made debugging less stressful, and even sparked creativity—making the journey of building Mystic-Quest much smoother and more enjoyable.

I have also upload this in my gthub also
https://github.com/morningstarxcdcode/Mystic-Quest

build with AmazonQDevCLI

AmazonQDevCLI

BuildGamesChallenge

give play ss