DEV Community: πn

TouchGrass FC: a Telegram bot whose only goal is to make you close Telegram

πn — Mon, 12 Oct 2026 06:05:27 +0000

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

What I Built

Every pickup football group has the same thread. "Saturday?" "Maybe." "What time?" "After work." "Which Saturday?" Twenty messages later, nobody has committed and nobody has played.

TouchGrass FC is a Telegram group bot that replaces that thread with one question and one poll. Someone types /play, and the bot asks everyone to reply with when they can make it, in their own words and whichever language they type in (it's built for Ukrainian, English, Spanish, German, Polish, French, Russian). A local Gemma model turns each reply into structured availability. From there it's plain code: check the 7-day forecast, drop any slot that wouldn't finish before sunset, pick the best one, find the nearest pitch on OpenStreetMap, and post exactly one poll with a map pin. Then the bot goes quiet, except for a reminder three hours before kickoff and one question afterwards: did you actually play?

That's the whole design for this week's theme. Per player, the interaction is one message and one tap on the poll. Per match, it's one /played from whoever remembers. The only metric I care about is the one /stats reports: ⚽ Matches actually played via this bot: N. (The bot's reply to /played is "Legendary. Logged. Go shower." Good advice, honestly.)

Did anyone actually touch grass?

Not yet, and I'd rather say so than invent a match. I've run the full loop in a live Telegram chat: messy replies in; weather score, pitch pin and poll out; reminder queued. But any number you see on /stats in my demo comes from me pressing the button to test it, not from a game. I'll update this post after the first real one.

Demo

The bot runs on my machine, so there's no live link. Here's a walkthrough in a real Telegram chat:

No bot token? python -m touchgrass simulate replays a scripted group chat in your terminal (more on that below).

Code

budulay / touchgrass-fc

A Telegram group bot that turns messy "when can you play?" chatter into ONE poll for a real-life pickup football match — then goes quiet so people actually go outside.

touchgrass-fc

A Telegram group bot that turns messy "when can you play?" chatter into ONE poll for a real-life pickup football match — then goes quiet so people actually go outside.

View on GitHub

MIT licensed, and a brand-new repo started during the challenge window.

How I Built It

One rule shaped everything: the model only gets the job code can't do, which is reading human messages. Everything else is boring, testable code.

Python 3.11+, aiogram 3: long polling (no server needed), privacy mode ON
Gemma 3 via Ollama: local inference, with Pydantic v2 validating every output
SQLite (aiosqlite): all state stays on the machine
Open-Meteo, Nominatim, Overpass: free and keyless; weather and map lookups are the only things that leave the machine

Reading messy messages

People don't write schemas. "можу в суботу після 18, якщо не дощ", "Sat morning I'm in" and "пятница после обеда" all have to land in the same structure. Ollama's format parameter accepts a JSON schema, so each request carries the Pydantic model's schema, at temperature 0 (abridged):

payload = {
    "model": model,
    "stream": False,
    "options": {"temperature": 0},
    "format": _SCHEMA,  # Pydantic JSON schema
    "messages": [{"role": "system", ...}, {"role": "user", "content": message}],
}

For the first message above, the output looks roughly like this (abridged):

{
  "can_play": true,
  "slots": [{"weekday": "saturday", "start": "18:00", "end": null}],
  "conditions": ["no_rain"],
  "language": "uk"
}

If validation fails, the error goes back to the model together with the original message, once. If that fails too, the bot asks the player to rephrase instead of guessing. One gotcha worth passing on: Ollama's format wants the complete JSON Schema object, not just the $defs block that Pydantic nests sub-models under.

The planner is deliberately dumb

score = player_count × weather_score. Weather score is a 60% rain penalty plus a 40% wind penalty, averaged over the slot window. Any slot ending after sunset (with a 15-minute buffer) is filtered out before scoring. No LLM involved: it's just numbers, which means it's unit-tested on recorded fixtures instead of vibes.

Does the model actually work?

The repo has 40 labelled messages in Ukrainian, Russian and English: slang, negations, conditionals, vague ranges like "можу в будь-який день після 19". The eval harness runs them against each Gemma size:

Model	Overall	can_play	language	slots	conditions	avg_lat	p95_lat
`gemma3:1b`	18%	45%	48%	55%	80%	6.6s	16.1s
`gemma3:4b`	28%	88%	50%	72%	88%	23.2s	36.1s

The Overall column is the harshest number in the table, and I'm showing it anyway. Per field, gemma3:4b is reasonable at what the planner needs most: whether someone can play (88%), under what conditions (88%), and roughly when (72%). Language detection sits around 50% for both sizes; it mostly decides which language the invite is written in, and I haven't dug into why it's so weak yet.

Speed is the other cost. On my machine [TODO: one line on your hardware, e.g. "a laptop with no GPU"], gemma3:4b takes 23 seconds per message on average (p95: 36 s). gemma3:1b is about 3.5× faster but gets can_play wrong more than half the time. So 4b is the default, and when it returns garbage the bot asks instead of guessing. For a group that coordinates once a week, I can live with 23 seconds. For anything conversational, I couldn't.

Try it without Telegram

python -m touchgrass simulate replays a scripted group conversation in your terminal, runs the real planner on synthetic weather, and prints a transcript. If Ollama is running, it uses the real model, so you'll wait as long as the numbers above suggest. If it isn't, it falls back to canned parses: you see the flow in seconds, but you're not seeing the model.

What doesn't work (yet)

The pitch search finds pitches that exist in OpenStreetMap. It has no idea whether one is free or bookable.
One location per chat, set with /setlocation.
Privacy mode stays on, so the bot only reads replies to its own message and /in. If you don't reply to the bot, as far as it knows you don't exist.

Why Does Open Innovation Matter?

I didn't benchmark a hosted model, so I won't pretend to know by how much it would beat a 4B Gemma on accuracy or speed. My guess is easily. Here's what going open bought me instead:

Nobody new reads the chat. The messages already live in Telegram. The question is whether a second company's API also gets to read who's free on Thursday evenings. Here, inference runs on the same machine as the bot, so it doesn't.
A model I can pin, swap and measure. I picked an exact model tag and ran the same 40 fixtures against two sizes; the table above is the result. Going from 1b to 4b is one environment variable (OLLAMA_MODEL), and nothing changes underneath me between runs.
Contributors don't need keys. The extraction schema is a Pydantic model in nlu.py, and the 29 tests run without network access. Anyone can change the schema, rerun the suite and open a PR without asking me, or a vendor, for credentials.

Cost, honestly, isn't an argument at this scale: a few dozen inferences are cents on any hosted API. It only becomes one when a bot like this has real users.

My Agent Session

I built this in Google's Antigravity from one written brief, split into three parallel workstreams: language understanding plus the eval fixtures; planner, weather and pitch lookup; and the Telegram layer plus the simulator. The agent wrote the code, the 29 tests and the first draft of this post. I ran the result in a live Telegram chat, then edited this write-up.

Prize Categories

Best Use of Gemma: Gemma 3 (via Ollama) is the only model in the project. It does the multilingual message understanding and writes the two-sentence invite in the group's dominant language. It runs locally, and the repo benchmarks it at two sizes (gemma3:1b and gemma3:4b) on the same 40 fixtures. The results are in the eval section above, including the parts that don't flatter it.

The bot's best feature is that it knows when to stop talking. This post is trying to learn from it.

CustomsBuddy: Your customs broker for international parcels

πn — Wed, 04 Mar 2026 20:06:54 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

Sending international packages is a pain. Especially when it comes to filling out customs declarations (CN22/CN23).

The average user doesn't know what "HS Codes" are, doesn't know how to correctly translate the names of specific items into English customs language, and often doesn't even realize that their favorite homemade cookies or cold pills are prohibited from being imported into the destination country.

To solve this problem, I created CustomsBuddy — a React application that converts a user's chaotic text description of a package into a rigorous, validated array of data.

In this article, I'll show how we abandoned unreliable text parsing and used Structured Output (JSON Schema) and dynamic System Instructions in the Gemini API.

Demo:

🛑 Why don't regular prompts work for UI?

Let's imagine a typical input: "I'm sending two used t-shirts, a new book, homemade cookies, and 50 bucks worth of medicine to Canada."

If you ask a regular LLM to "make a table out of this," it will return Markdown. Markdown looks great in chat, but as a developer, I need to draw React components: green checkmarks for allowed items, red warnings for prohibited items, and calculate the total.

I need predictable JSON.

🛠 Solution: Gemini Structured Output

Instead of begging the model to "please return only JSON," we use the responseSchema parameter in the Gemini API. This forces the model to strictly follow the structure we specify.

Step 1: Define the Ideal Structure (The Schema)

Here is the configuration object that we will pass to the API:

const responseSchema = {
  type: "OBJECT",
  properties: {
    items: {
      type: "ARRAY",
      items: {
        type: "OBJECT",
        properties: {
          original_description: { type: "STRING" },
          customs_description_en: { type: "STRING" },
          hs_code: { type: "STRING" }, // International customs code
          quantity: { type: "INTEGER" },
          weight_kg: { type: "NUMBER" },
          value_usd: { type: "NUMBER" },
          is_allowed: { type: "BOOLEAN" }, // The main trigger for UI!
          warning_reason: { type: "STRING" } // Explanation if prohibited
        },
        required: ["original_description", "customs_description_en", "hs_code", "quantity", "weight_kg", "value_usd", "is_allowed", "warning_reason"]
      }
    },
    general_warnings: {
      type: "ARRAY",
      items: { type: "STRING" }
    }
  },
  required: ["items", "general_warnings"]
};

Step 2: Dynamic System Instructions

Our app supports different destination countries (USA, Canada, Germany, etc.) and different interface languages. The US customs rules are different from Germany. That's why we make the systemInstruction dynamic!

In the React component, before calling the API, we form the instruction:

// Get the country name in English and the language for the explanation
const destCountryEn = countries.find(c => c.code === destination).name.en;
const explanationLang = lang === 'uk' ? 'українською мовою' : 'in English';

const systemInstruction = `You are a professional international customs broker.
Your task: to analyze user input to send parcels to the country: ${destCountryEn}.
1. Translate the product descriptions into strict, standardized English.
2. Determine the exact 6-digit HS Code.
3. Logically distribute the cost/weight if only the total is specified.
4. STRONG VALIDATION: Check the customs rules of the country ${destCountryEn}. If the item is prohibited (e.g., homemade food, certain medications), set is_allowed: false and explain why, ${explanationLang} is mandatory. Respond strictly in JSON format.`;

Step 3: Calling the Gemini API

Now we send all this to gemini-2.5-flash:

const response = await fetch(`https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-preview-09-2025:generateContent?key=${apiKey}`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
  contents: [{ parts: [{ text: inputText }] }],
  systemInstruction: { parts: [{ text: systemInstruction }] },
  generationConfig: {
    responseMimeType: "application/json",
    responseSchema: responseSchema // Inserting our schema!
  }
 })
});

const data = await response.json();
const jsonText = data.candidates[0].content.parts[0].text;
const parsedDeclaration = JSON.parse(jsonText);
// That's it! No regular expressions or text truncation!

🎯 How does this look in practice?

When a user types: "I'm sending two T-shirts, a book, homemade cookies, and $50 worth of cold medicine to Canada"...

Gemini returns a perfect JSON where for the book and T-shirts is_allowed: true (and the model itself found the HS codes 4901.99 and 6309.00 for them). But for the cookies and medicine, the model returns is_allowed: false and adds an explanation that Canadian customs blocks homemade food without factory labeling and over-the-counter medicines.

In React, we simply map this array:

{results.items.map((item, idx) => ( 
 <div key={idx} className={item.is_allowed ? 'bg-slate-50' : 'bg-red-50'}> 
  {item.is_allowed ? <CheckCircle2 className="text-emerald-500" /> : <AlertOctagon className="text-red-500" />} 

  <h3>{item.customs_description_en}</h3> 
  <span>HS Code: {item.hs_code}</span> 

  {!item.is_allowed && ( 
  <div className="text-red-700"> 
   Failure reason: {item.warning_reason} 
  </div> 
  )} 
 </div>
))}

💡 Conclusion

Structured Output (JSON Schema) completely changes the approach to developing AI applications. We no longer use LLMs simply as "smart interlocutors". We use them as reliable microservices for data analysis, classification and transformation that integrate perfectly into our frontend.

Try adding responseSchema to your next Gemini project - and you will forget about the pain of text parsing forever!

Maplewood Heights (Community Connect)

πn — Mon, 02 Mar 2026 07:55:04 +0000

This is a submission for the DEV Weekend Challenge: Community

Today I’m excited to introduce Maplewood Heights, a warm and inviting hub for our local community!

🏡 It’s a place where neighbors can learn about events, share news, and discover local gems.

☁️ I'd love to hear your thoughts on the design!

The app is already deployed to Google Cloud:: https://community-connect-528833377593.us-central1.run.app

🛠️ Functionality of the first version already has a lot of useful features:
📅 View upcoming events
💬 Live feed of community updates
☕ Favorite local places
🤝 Neighbor profiles and statistics

Updates feed: Multi-level comment threads, quick reactions, and emojis.
Community: Get to know your neighbors and quickly message them.
Events: A board of upcoming activities (from farmers' markets to volunteering).
Local "gems": Recommendations for the best bakeries, parks, or coffee shops in the area.

My main goal was to combine the speed of modern frontend technologies with a stylish, warm UI.

Stack & Architecture:
⚡ React 18 + Vite (quick build via SWC)
🎨 Tailwind CSS v3 + CSS-variables (fully custom light/dark theme in honey/sage green tones)
🧱 shadcn/ui (integrated ~50 Radix UI components)
✨ Framer Motion (controls orchestrating animations when scrolling and microinteractions)
🚢 CI/CD: Multi-stage Docker build on top of Nginx -> deployment to Google Cloud Run.

What's inside?

Watercolor hero block.
Update feed with support for recursive N-level comments and reactions.
Neighborhood mutual aid module.
Own context-messaging right in the browser.
When design (DM Serif Display + warm tones) works in synergy with cool UX, users really want to come back.

Happy to connect people through technology. ✨

My Portfolio Has a Split Personality: GUI vs Terminal

πn — Mon, 02 Feb 2026 07:58:24 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

Hello, network! 👋

For the "New Year, New You" challenge, I didn't want to just update my CSS. I wanted to build something that represents the duality of a Full Stack Developer:

The Professional: Clean, modern UI using the trendy Bento Grid layout.

The Geek: A hacker-style Terminal for those who prefer CLI over GUI.

Try it out!
Check out the live demo and let me know: are you team #GUI or team #Terminal? 👇

Available at: https://devportfolio-528833377593.us-central1.run.app/ 🚀

The Concept

Usually, portfolios are static. You read, you scroll, you leave. I wanted interaction.

GUI Mode: Visualizes my projects and skills.
Terminal Mode: Lets you type commands like help, skills, or even ask to talk to AI.

The AI Magic ✨

Instead of searching for my experience in a long text, recruiters can now ask:

"Tell me about your skills?"

The AI analyzes my JSON data and generates a professional answer instantly. It lives both in a chat modal (GUI) and as a command (Terminal).

Tech Stack

Framework: React + Vite
Styling: Tailwind CSS
AI: Google Gemini API
Icons: Lucide React

The most time was spent not on the code, but on making the site feel "like me": a little mysterious, a little playful, but at the same time very professional.

This is not just a portfolio. This is my manifesto for 2026: code with passion, use the best tools (thanks Google AI) and don't be afraid to be yourself.

Thanks for stopping by.

Write in the comments what you liked/what you would change - I'd be happy to hear your feedback.
And if you also participated - drop a link, I'll take a look and like 🚀