DEV Community: Bob D

workout-suggester: checks the weather and Gemma sends you outside

Bob D — Sun, 11 Oct 2026 17:50:44 +0000

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

What I Built

In Belgium the weather gets a vote on every workout: is it nice enough to go out, or is it another day inside? A weather app doesn't really answer that.

workout-suggester answers it for you. You tap 📍 Here and pick what you're up for (run, ride, walk, or "surprise me"), how hard, and how long. A few seconds later you get:

Scores for the next hour or two: run, ride and walk each scored 0–100 for the actual weather window, with the reasons ("strong gusts up to 50 km/h", "dark: bring lights").
A pick and a plan: what to do, when to go, a warm-up / main set / cool-down that fits your intensity and time, what to wear, and a plan B. If it's truly grim, it sends you inside with a concrete HIIT session instead.
A route: a loop of the right length that starts and ends at your door, heading out into the wind so you come home with a tailwind. Nearby signposted OpenStreetMap routes (fietsroutes, wandelroutes, the nearest knooppunt) are listed too. Every route has a GPX download for your watch or bike computer.
Follow-ups: "make it harder", "I only have 30 minutes".

The screen part takes about a minute. After that the GPX is on your watch and your phone stays in your pocket.

It's for anyone who wants to move more but loses the first 20 minutes to weather apps and indecision.

Demo

On a phone, which is where you'll use it:

Code

git.b0b.be/bdeb/workout-suggester

It's one ~9 MB Go binary. Point it at any OpenAI-compatible model server and run it:

cp .env.example .env   # LLM_BASE_URL=http://127.0.0.1:8000/v1 (oMLX), or llama.cpp, Ollama, LM Studio...
make run               # → http://127.0.0.1:3000

How I Built It

The model: Gemma 4 E2B, running locally. I used gemma-4-E2B-it-qat-4bit through oMLX on a MacBook. Any OpenAI-compatible server works (llama.cpp, Ollama, LM Studio), and you swap models with one environment variable. A plan streams in about 10 seconds.

Stack: Go, Templ and HTMX, with the model's reply streamed over server-sent events. A Leaflet map shows the routes. The stack comes from my previous week's project and stays small and fast.

The most important design decision: don't let the small model do the maths. A 2B model will happily say "light breeze" about 50 km/h gusts, or invent a sunset time. So the work is split:

The weather comes from open data. Open-Meteo is open source and needs no key. If it's overloaded (that happened during the build), the app falls back to MET Norway, then to the last forecast it had. MET Norway has no gusts for Belgium, so gusts are estimated from wind speed and marked "≈". Sunrise and sunset are calculated locally.
Plain Go rules do the scoring. Each activity starts at 100 and loses points per condition, weighted by activity. Gusts over 45 km/h cost a ride 40 points but a run only 15. Heavy rain costs everything a lot. Thunder is a flat zero. Below 40 everywhere, you go inside. The app also looks 12 hours ahead for a clearly better daylight window ("better at 17:00").
Routes come from open routing. BRouter generates round trips from your door in three directions, starting into the wind. Overpass finds signposted OpenStreetMap routes nearby and the nearest knooppunt. BRouter's round-trip parameter turned out to behave like a radius (ask for 10 km, get ~51 km), so the app scales it down. Long-distance trails like the 130 km Streek-GR get filtered out.
Gemma writes the plan. All of that goes into the system prompt as a short sheet of facts: the weather, the scores and reasons, the pick, the target distance and pace, and the routes with their climb, paved percentage and wind direction. Gemma does what small models are good at. It explains the pick in plain language and builds a workout around it, and follow-ups like "only 30 minutes" can reshape the session.

Splitting it like this is what made E2B good enough. It never decides whether it's safe to ride. It gets told, and it explains.

Why Does Open Innovation Matter?

Every part can be self-hosted or swapped. The model, Open-Meteo, Overpass and BRouter are all open source, and each has one environment variable to point it at your own instance. When Open-Meteo went down mid-build, adding a fallback was a small change, not a vendor problem. If E2B isn't good enough, I switch LLM_MODEL to E4B, no new API key or pricing page needed.

It costs nothing to run. There's no per-token bill for a question I ask every morning, and no subscription for weather or routing.

OpenStreetMap knows the local routes. Flanders has signposted cycling and walking networks, numbered junctions and small park loops. They're all in OSM, mapped by volunteers. No closed fitness API gives me that for free, and none would let me generate a loop from my front door that heads into the wind first.

Route data keeps working without a connection. Signposted routes are cached on disk for a week, and the GPX goes to your watch. Once you've planned, you don't need the screen or the signal.

A closed stack would have given me a nicer chatbot and a worse product. The useful part is having the data, the routing and the model under my own control, glued together with about 3,000 lines of Go.

Prize Categories

Best Use of Gemma. Gemma 4 E2B, running locally, is the coach: it turns rules-based weather scores and OpenStreetMap routes into a concrete workout plan, and handles the follow-ups.

localchat: yet another local chat app POC w/GoLang + HTMX

Bob D — Mon, 05 Oct 2026 06:01:14 +0000

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

What I Built

localchat is a chat app for an AI model that runs on your own machine. A Go server renders the UI, and Google's Gemma 4 E2B writes the replies, streamed into your browser token by token. Your messages stay in memory on your laptop for as long as you run the app.

I talked to a friend before about what a bare-basic and simple Go web app with AI integration would look like, without too many difficult parts. So I spent some time setting this up and kept the project small enough to read in one sitting.

I picked Gemma while developing because I like running small models on my own hardware. Gemma 4 E2B fits in a few gigabytes of RAM and starts answering in about a second on my laptop. It's fast and easy to develop against while still having realistic output.

My friend and I get two things:

Code you can read in an evening. A HTML form posts to a Go handler, the handler calls the model, and the reply streams back into the page.
A base to build on. You can change the system prompt, swap the model with one environment variable, or install the app as a background service on Linux, macOS or Windows. You can also run it as a container if you like.

Code

Repo: git.b0b.be/bdeb/localchat

cmd/localchat/          entry point: serve + install/start/stop as an OS service
internal/llm/           ~150-line OpenAI-compatible streaming client (stdlib only)
internal/chat/          in-memory conversations, one per browser session
internal/web/           routes, SSE streaming, embedded static assets
internal/web/views/     Templ components
scripts/e2e.py          Playwright browser test against the real model
compose.yaml            app + llama.cpp + Gemma 4 E2B

Demo

Video Demonstration

On my M3 MacBook Air, Gemma 4 E2B (4-bit, through oMLX) sends its first token after about a second and finishes a short answer with a code block in 3 to 5 seconds.

How I Built It

Open-source AI: Google's Gemma 4 E2B (open weights, 4-bit). I ran it with oMLX (Apple MLX) on my Mac while developing, and the container uses llama.cpp (llama-server with a GGUF build).

App stack: Go 1.27, Templ, HTMX 2 with its SSE extension, goldmark and kardianos/service.

Browser ── HTMX + SSE extension
  │  POST /chat              → user bubble + empty reply bubble (sse-connect)
  │  GET  /chat/stream/{id}  ← "token" events (append) … "done" (swap in Markdown)
Go (net/http + Templ)
  │  POST /v1/chat/completions {stream: true}
Local model server ── Gemma 4 E2B

Streaming works as plain HTML over server-sent events:

Your browser posts the message, and the server answers with two Templ fragments: your message and an empty reply bubble with sse-connect="/chat/stream/{id}".
The Go handler streams the model's reply and wraps each chunk in an HTML-escaped <span> inside a token event. HTMX appends each span with hx-swap="beforeend", so you see the answer appear word by word. I wrote no JavaScript for the streaming.
Once the model finishes, the handler sends a done event carrying the reply as server-rendered Markdown (goldmark, raw HTML stripped). HTMX swaps the whole bubble for it, and removing the sse-connect element closes the stream.
Browsers reconnect a dropped EventSource on their own. If one reconnects for a finished reply, the handler sends back the final HTML and skips the model. A test checks that the model runs once per reply.

A few more details:

I used no AI SDK. The client reads OpenAI-compatible streaming with a bufio.Scanner over data: lines, in about 150 lines of standard-library Go.
localchat install --user registers the app as a launchd agent, a systemd unit or a Windows service, pointed at your .env file.
I embedded htmx, the SSE extension, the CSS and the icon in the binary, so the app works offline.
Handler tests run against a fake OpenAI-style server and cover streaming, history, session isolation, XSS-safe Markdown and an offline model. A Playwright test drives a real browser against Gemma, both on the Mac and in Docker.

Prize Categories

Best Use of Gemma: localchat runs Google's Gemma 4 E2B on your own machine, through MLX on a Mac or a GGUF build in llama.cpp under Docker.