DEV Community: Rajdeep Dolui

Dhire Dhire: a slow, offline History study helper for a 3.6 GB laptop tags: devchallenge, hf26challenge

Rajdeep Dolui — Tue, 20 Oct 2026 06:34:51 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 3 — Slow and Steady
What I Built
I'm a History student at Burdwan University. My laptop has about 3.6 GB of RAM, so most AI tools either need the internet or need more memory than I have.
For "Slow and Steady," I built around that limit instead of fighting it. Dhire Dhire (ধীরে ধীরে, "slowly, slowly") is an offline study helper. You give it your notes or textbook text. It cuts the text into small chunks and works through them one at a time with Gemma 3 1B, turning each chunk into exam-style questions with short answers.
After every chunk it saves a checkpoint. If my laptop sleeps or crashes, I run it again and it continues from where it stopped. I can start it at night and read the results in the morning.
It's for students like me: limited hardware, patchy internet, a lot of reading.
Code
https://github.com/bidyutdolui1970-cpu/dhire-dhire
It's plain Python with no dependencies, plus Ollama for running the model. I built it during the Week 3 window, with AI assistance for writing the code and tests.
How I Built It
Model: Gemma 3 1B (gemma3:1b), run locally through Ollama with a small context window to keep memory low.
Chunking: text is split at sentence ends, including the Bengali danda (।), into chunks of about 180 words.
Checkpoints: every finished chunk is saved to SQLite immediately. A chunk only counts as done after its answer is saved, so an interrupted chunk is simply redone. I wrote tests that interrupt a run halfway and check that the restart only does the remaining work.
Output: a Markdown notes file and a CSV of flashcards. If the model ignores the Q/A format, its raw text is kept instead of thrown away.
Measured on my laptop: RAM in use while running: 26 GB. Seconds per chunk: 5 s. Total run time for my test notes:6 min.
Why Open Innovation Matters Here
It runs offline. After the one-time model download, no internet is needed.
It's free. No API bill and no per-token cost, which matters for a student.
It's private. My notes never leave the laptop.
I can swap models. If a better small model appears, I change one setting (Gemma model) and the rest of the pipeline stays the same.
Where it beat a cloud approach: a cloud API would be faster per request, but it needs internet, costs money and sends my material to someone else's server. Slow but always available fits my situation better.
Prize Categories
Best Use of Gemma: Gemma 3 1B is the core of the project and runs fully locally on a 3.6 GB laptop.

"Dokan Khata: A Voice Notebook for Shopkeepers Who Sell on Credit, Powered by Gemma and Whisper"

Rajdeep Dolui — Tue, 13 Oct 2026 10:52:52 +0000

ROLE
You are an editor helping me write a DEV Community challenge post. The write-up is the most heavily weighted judging criterion, so clarity, honesty and a human voice matter more than polish.

TASK
Write my submission post for the "Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle". Use exactly this structure:

title: "Dokan Khata: A Voice Notebook for Shopkeepers Who Sell on Credit, Powered by Gemma and Whisper"
published: false

tags: devchallenge, hf26challenge

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

Then these headings, in order:

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My First User (include ONLY if I give real facts below, otherwise omit)

Prize Categories

FACTS (use only these; never invent anything)

Project: Dokan Khata, an offline Bengali voice ledger for corner shops. The shopkeeper speaks a credit sale, the app transcribes it, extracts customer/items/amount/due date, asks for confirmation, and updates the customer's balance. It also makes a weekly "who owes me" summary and polite Bengali reminder drafts.
Problem and who pays: [your words about the shopkeeper problem]
Models/tools used: faster-whisper small (int8), Gemma 3 1B (4-bit) via Ollama, SQLite, Flask [edit to match what you really used]
Hardware: low-end laptop, about 3.6 GB RAM, CPU only. Peak RAM measured: [number]
Measured results: [accuracy per field from my test set, latency per step]
Things that broke and how I fixed them: [paste from FAILURES.md]
Demo link/video: [link]
Repo link: [link]
First user (delete if none): [who, what they did, what they said, did they say they would pay]
Categories entered: Best Use of Gemma [add others only if truly used]

STYLE

First person, plain English, short paragraphs, no hype or buzzword stacking.
Open with a concrete scene (a shopkeeper with a paper notebook), not a definition.
In "Why Does Open Innovation Matter?" give specific reasons tied to my facts: customer data stays on the laptop, works offline, zero per-use cost, adaptable to Bengali. Say where a closed API would have been worse.
Include at least one honest failure and what I learned.
If a fact is missing, leave a [PLACEHOLDER] instead of guessing.
Under 900 words.

AFTER THE DRAFT
List the placeholders I still need to fill, and flag any claim that is weaker than it sounds.

Fridge Forecast: a weekly outdoor plan you print once and never look up again

Rajdeep Dolui — Tue, 06 Oct 2026 03:42:41 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Apps that tell you to go outside have an obvious flaw: you have to open an app.

Fridge Forecast moves the whole thing onto paper. Once a week, you export your calendar and run one command. It finds the free windows in your week, checks the forecast for each, and prints a one-page card for the fridge showing the best times to go outside and what to do with them. After that, the screen's job is finished.

Demo

The flow has three steps:

Export your calendar as an .ics file and add a line about what you like.
Run Fridge Forecast. It picks the best windows and writes a suggestion for each.
Print the card and put it on the fridge.

How I Built It

Everything runs locally except the forecast lookup:

Calendar: the icalendar library reads your .ics file and works out free windows.
Forecast: Open-Meteo, a free open API that needs no key.
Choosing windows: plain code scores each window on rain, wind, temperature, and daylight. The model never decides when you go out.
Suggestions: an open-weight Gemma model served through Ollama writes one friendly suggestion per chosen window, using your note about what you like.
Output: a printable HTML page.

The key design choice is the split. Code makes the decisions that must be right, such as when the weather is good and when you're free. The model only writes the human part. Its output is validated, and if it fails, fixed fallback text keeps the card complete.

Why Open Source AI

Privacy: your calendar shows when you're home, where you are, and who you meet. With a local model, it never leaves your machine.
Cost: it costs nothing to run, so it can be a weekly habit with no subscription.
Control: the scoring rules and the prompt are plain files you can edit to suit your own life.

OpenLoom: answers from your own documents, with a citation for every claim

Rajdeep Dolui — Sun, 04 Oct 2026 16:39:24 +0000

This is a submission for the MLH x DEV Writing Challenge

What I Built

Asking an AI about your own documents has an awkward trust problem. It gives a confident answer, and you have no idea whether it came from your files or from the model's imagination.

OpenLoom tackles that. You upload your PDFs and notes, ask a question, and OpenLoom answers using only those documents. Every claim points back to the exact passage it came from, like a thread you can pull. If the answer isn't in your files, it says so instead of guessing.

The name comes from weaving: many separate threads of source material become one answer, and you can always trace it back.

Demo

The flow is simple:

Upload one or more PDFs or text files.
Ask a question in plain language.
Read the answer, then expand any citation to see the original passage and the file and page it came from.

Code

bidyutdolui1970-cpu / my-public-repo

OpenLoom

OpenLoom is a lightweight platform for building and running AI-powered applications that leverage open models. It helps teams connect model workflows, orchestration logic, and deployment pipelines without locking themselves into a single proprietary provider.

What OpenLoom does

OpenLoom gives developers a practical way to:

orchestrate AI workflows and tool usage
connect applications to open-source large language models
manage prompts, data flows, and model calls in a reusable way
integrate AI features into products while keeping control over model choice and deployment
support experimentation and iteration across models and environments

In simple terms, OpenLoom helps turn model capabilities into usable application features with a clear and flexible architecture.

Where the open model is used

The open model is used in the model layer of OpenLoom, where it powers inference, reasoning, and task execution in a transparent and portable way. This is typically the place where:

chat and agent workflows run
…

View on GitHub

Open-Source Technologies

OpenLoom is built entirely from open pieces, and all of it runs locally:

Embeddings: sentence-transformers turns document chunks into vectors.
Vector search: Chroma stores the chunks and finds the most relevant ones for a question.
Language model: an open-weight Gemma model, served through Ollama, writes the answer from the retrieved passages only.
Interface: Streamlit for upload, questions, and source viewing.

The key design choice is the prompt. The model is told to answer only from the retrieved passages, cite them by number, and say "not found in your documents" when the evidence isn't there. That one rule is what makes the citations trustworthy.

What I Learned

Retrieval quality matters more than model size. Chunk size and overlap changed answer quality more than anything else, because a chunk that cuts a thought in half gives the model nothing useful to cite. Keeping the file name and page number attached to every chunk made citations nearly free to build.

Hackathon Experience

I built OpenLoom for Hacktoberfest 2026, MLH's open-source AI hackathon, where the goal was to build something new with open-source AI at its core. Building against that constraint pushed me toward local models, and that turned out to be the right call for a tool that handles people's private documents.

Recipe Keeper: turning a family member's voice notes into a recipe book, fully offline

Rajdeep Dolui — Sun, 04 Oct 2026 16:34:43 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Some of the best cooks in our families never write anything down. The recipes live in their heads, and the only trace is a rambling voice note that says things like "add salt until it feels right." When that person is gone, or just busy, the recipe goes with them.

Recipe Keeper is a small tool I built for a family member who cooks entirely from memory. You upload a voice note of them talking through a dish. The app transcribes it, then a local language model turns the transcript into a clean recipe card with ingredients, steps, and tips. Saved cards are collected into a printable family recipe book.

The goal was simple: let them keep cooking the way they always have, and let the rest of us finally hold on to the food.

Demo

The flow has three steps:

Upload a voice note, for example someone explaining how they make a dish.
Review the transcript and the generated recipe card side by side, and fix anything the model got wrong.
Save the card. All saved recipes are combined into one recipe book you can print.

How I Built It

Everything runs on a single laptop, with no cloud services and no API keys:

Speech-to-text: Whisper, run through faster-whisper. It supports many languages, which matters because spoken recipes often mix languages.
Structuring: an open-weight Gemma model served locally with Ollama. I prompt it to return strict JSON with a title, ingredients, steps, and tips, then validate the JSON before showing it.
Interface: a simple Streamlit app for upload, review, and editing.
Output: an HTML recipe book generated from the saved recipes, which can be printed to PDF.

The trickiest design problem is that spoken recipes are vague ("a handful", "until it smells right"). The prompt tells the model to keep the speaker's own wording and never invent exact measurements, and the review step lets a human correct anything before it is saved.

Why Does Open Innovation Matter?

Privacy: these are family voice recordings. With local models they never leave the laptop, and no company's server ever hears them.
Cost: it costs nothing to run, so there is no API bill for something a family might use for years.
Control: if transcription is weak for a particular accent or language, I can switch to a larger Whisper model or adjust the prompt. With a closed API, I would be stuck with whatever it gives me.
Offline: it works in the kitchen, with no internet connection needed.

For something as personal as a family member's voice and recipes, keeping everything local made more sense than any cloud service could.