DEV Community: Jason Steinshouer

Trail Bingo: a hiking game whose photo check runs on your phone, with no signal

Jason Steinshouer — Sun, 11 Oct 2026 15:47:59 +0000

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

What I Built

Trail Bingo is a bingo game you play on a hike.

Before you leave home, you build a Card for your trail. The app asks iNaturalist what people have actually seen within 10 km of that spot at this time of year, and deals out a 3×3, 4×4 or 5×5 Card from it: a bur oak, Canada goldenrod, a splitgill mushroom, "a mammal", "a butterfly or moth". The middle Square is a Wildcard that anything living can fill.

On the trail, when you spot something on your Card, you tap one button and take a photo. An open model on your phone checks it against your Card, with no signal and nothing sent anywhere:

Sure: the Square is marked Verified.
Not sure: it shows its top three guesses, and the one you pick is marked Confirmed.
Either way: you get a short fact card (a photo, two or three sentences from Wikipedia) and dismiss it with one tap.

Fill a row, column or diagonal and you get a Bingo; fill everything and you get a Blackout. Then the phone goes back in your pocket.

I thought it could be an tool to educate and help engage with nature. It's built for casual hikers and families, so the copy is written for kids to follow, and the animal Squares are broad on purpose: "a bird" counts whether or not you can tell a junco from a sparrow.

Demo

Play it: sparkly-selkie-a49b7b.netlify.app

It's made for Chrome on Android; desktop Chrome with a webcam should work too. The first launch downloads the photo check's model once (about 300 MB), so use Wi-Fi. After that, building a Card needs signal, and playing doesn't. You can install it to your home screen and play a whole game in airplane mode.

System requirements

Browser: Chrome (or another Chromium browser) on Android, which is what it's tested on. iPhone and Safari aren't supported yet.
Storage: about 450 MB free, for the model and a Card's photos and facts.
Camera: every Sighting is a photo.
Best with WebGPU and 4 GB or more of memory. On my phone, a photo check takes about 1.3 seconds.
- Phones with 2–4 GB run a lighter mode that uses about half the memory, but checks more slowly.
- Without WebGPU, each check takes a few seconds, and building a Card can take several minutes.
- Phones with 1 GB or less can't run it.

You don't have to work any of this out yourself. The setup screen checks the phone before anything downloads, so a phone that can't run Trail Bingo is told why, instead of spending 300 MB to find out.

Work in progress

Some more field testing still needs to be done to tune the model for more accurate identification. See the Tune the confidence gap from real Sightings section for more info.

Code

jsteinshouer / trail-bingo

The model export is published on Hugging Face: jsteinshouer/trail-bingo-bioclip-onnx.

How I Built It

The model: BioCLIP, in the browser

The photo check is BioCLIP (Imageomics Institute, MIT licence), a CLIP-style model trained on the tree of life to match photos of organisms to their taxon names. That's exactly the question the game asks: which of the Squares on this Card is this?

No browser-ready build of both BioCLIP encoders existed, so I exported them myself:

Export: the image encoder and the text encoder, both to ONNX.
Weights: stored as fp16 and computed in fp32. That halves the download with no accuracy loss. (Full fp16 math crashes ONNX Runtime's WebAssembly backend, and plain int8 quantization measurably hurt this ViT.)
Parity: the export script fails if either encoder drifts below 0.99 cosine similarity from PyTorch. Both came out at 1.000.

In the app, ONNX Runtime Web runs the model in a Web Worker, on WebGPU where the phone has it and WebAssembly where it doesn't. Hugging Face's tokenizers.js tokenizes labels exactly as open_clip does.

The first thing I did was a one-day spike to find out whether this was even possible on my phone (Android 10, Chrome, PowerVR GPU). It was: WebGPU, about 6 seconds to load from storage, about 1.3 seconds per photo check.

A static app that works in airplane mode

There's no backend:

Hosting: the app is a static site on Netlify.
The model: it comes from my Hugging Face repo, stored in the browser's Cache API on first launch.
The Card, marks and photos: kept in IndexedDB, so closing the app or restarting the phone mid-hike loses nothing.
Offline: a service worker keeps the app shell, so the installed app opens with no signal.

Before the big download, a device check makes sure the phone can actually run it. The stack is Vite and TypeScript with no framework, and Vitest tests the game logic through fake adapters.

Why Does Open Innovation Matter?

Every reason Trail Bingo works comes down to the model being open.

It works where hikes happen. Most of the trails I care about have no signal. A closed vision API needs a connection for every photo. Because BioCLIP's weights are open, I could export it, put it in the browser and run it on the phone itself. The trail is offline, so the AI has to be too.
Your location and photos stay yours. A hosted API would see where you're hiking and every photo you take, often of your kids. Here, photos never leave the phone. The only thing that sees your (rounded) location is iNaturalist, when you build a Card. There's an opt-in hike log I added for tuning the photo check, and even that only leaves when you export it yourself.
The right tool beats the biggest one. I considered a general model like Gemma, but its browser build is about 2.5 GB, more than a phone tab can bear. It's also a text generator, not a species matcher. BioCLIP is smaller, made for exactly this question, and its open training and evaluation told me what to expect. Open meant I could choose the specialist.
It costs nothing to run. No inference bill, no API keys, no server. A static host and a free model repository serve it, and each player's phone does the work.
Open goes both ways. Because the model and licence are open, I could adapt it, measure it against PyTorch, and publish the browser-ready export back to Hugging Face with credit to the BioCLIP team, so the next person doesn't have to.

Taking It Outside

More field testing, and better identification

So far I have only had time to do testing in my back yard and havent had time to do more extensive field testing. That automated testing used research-grade iNaturalist photos, the kind BioCLIP partly learned from, so real Sightings will probably do worse: taken one-handed, in shade or wind, often from too far away.

Even in the desk test, the misses had a pattern:

Look-alikes: bluestem grasses, goldenrods, sunflowers and shelf fungi.
"Another insect": the weakest animal group, right on only 7 of 12 photos.

Trail Bingo needs a lot more time outside before I'd call its identification reliable. Here's what I'll adjust as the field data comes in:

Tune the confidence gap from real Sightings. It's 0.03 now, set from the desk test. The hike log records every Sighting's top matches and scores, so I can see how many wrong answers slipped through as Verified and how many right ones needlessly asked. Then I'll move the threshold, or set one per group.
Treat look-alikes honestly. When the top matches are close relatives, the game should ask rather than guess, or let a Square accept a near-identical species from the same genus.
Test the label wording per group. "Scientific name plus common name" did as well as BioCLIP's full-taxonomy format for plants, but insects and fungi may need different wording.
Fine-tune on local photos. Because BioCLIP's weights are open, it could be fine-tuned on a region's own iNaturalist photos. That's a bigger step, and one a closed API wouldn't let me take at all.

What's Next

Field test, then tune. More hikes with the hike log on, and the adjustments above.
Shrink the download without hurting accuracy.
Support iPhones, which aren't a target yet.

Trail Bingo was built with Claude Code as a coding partner, and this post was drafted with AI assistance and edited by me.

Herding Cats: a Raspberry Pi that plans the school-activity drives, with a local LLM

Jason Steinshouer — Mon, 05 Oct 2026 02:32:45 +0000

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

What I Built

In our house, one person does most of the driving: soccer practice, piano, dentist, birthday parties. We have a shared calendar for all the activities but my wife keeps a lot of logistics in here head. Things like: When do I have to leave? Can I get from piano to the soccer game in time? Do I need backup tomorrow?

On top of that, every coach, school and studio sends schedule changes by email, and someone has to copy each one into the shared calendar by hand.

The goal of this is to ease the burden by having AI help ease the burden of updating the calendar and working out transportation logistics.

Herding Cats (the Family Drive Planner) is a small service on a Raspberry Pi that does two jobs:

Nightly briefing. Every evening it emails both parents tomorrow's plan. For each event it shows when to leave and how long the drive is. It flags clashes and says which drives need the second parent.
Email to events. Forward an activity email to a dedicated inbox. The Pi reads it, pulls out the events and replies with one calendar invite per event. Accept the invite in Outlook and the event lands on the shared family calendar.

There's no app to install and no new habit to learn. It works with email and the calendar we already use.

Demo

This is a real run of both flows against the local model (qwen2.5:1.5b-instruct). Everything is placeholder data: made-up kids, made-up places, example.com addresses. One honest caveat: I didn't have an OpenRouteService key on the dev box, so drive times in this run come from a straight-line-distance stub. In production they come from ORS and are cached in SQLite.

1. Nightly briefing: a busy Saturday

Subject: Tomorrow's plan: Sat Oct 11

Tomorrow is Saturday, October 11. Sam has a piano lesson at 9:30 AM, leaving by
9:03 AM, and the drive is 17 minutes. Alex's soccer game starts at 10:30 AM,
leaving by 9:52 AM, and the drive is 28 minutes. Sam's birthday party is at
2:00 PM, and the drive is not specified. Alex's game conflicts with Sam's piano lesson.

Second driver needed: Alex soccer game (10:30 AM)

LEAVE BY  WHEN               EVENT               WHO   WHERE                     DRIVE   NOTES
9:03 AM   9:30 AM-10:15 AM   Sam piano lesson    Sam   Maple Music Studio        17 min
9:52 AM   10:30 AM-11:30 AM  Alex soccer game    Alex  Riverside Soccer Complex  28 min  SECOND DRIVER; conflicts with Sam piano lesson
          2:00 PM-4:00 PM    Sam birthday party  Sam   Jumpin' Jungle                    unknown place: add this venue to family.yaml

The table is built by plain code. The model only writes the paragraph on top. Notice that the birthday party gets "unknown place" rather than a guessed drive time.

2. Forwarded coach email → events + invites

The forward, after unwrapping (Gmail, Outlook and forward-as-attachment all work):

FYI for Alex

Hi families,

Practice moves to next Tuesday at 5:30 pm on Field 3. Please bring water.
Saturday's game is at 9:00 am at Riverside.

Thanks,
Coach Rivera

The reply that comes back:

Subject: Re: Fall soccer schedule update

Found 2 events. Accept each invite to add it to the calendar:

- Tue Oct 14, 5:30 PM: Practice (Alex) at Riverside Soccer Complex
  Notes: Please bring water
  (no end time given; the invite assumes one hour)
- Sat Oct 11, 9:00 AM: Game at Riverside Soccer Complex
  (no end time given; the invite assumes one hour)

Plus one .ics invite per event (METHOD:REQUEST, so Outlook shows Accept/Decline):

BEGIN:VEVENT
SUMMARY:Alex: Practice
DTSTART;TZID=America/Chicago:20251014T173000
DTEND;TZID=America/Chicago:20251014T183000
LOCATION:200 River Rd\, Springfield\, IL
DESCRIPTION:Please bring water
...

"Next Tuesday" resolved to Oct 14 because the coach sent the email on Mon Oct 6. The date is read from the forward header, not from when it was forwarded. "Field 3" matched a venue alias in family.yaml.

Code

jsteinshouer / herding-cats

Family Drive Planner

A Raspberry Pi service for the parent who drives the kids to most of their activities. It does two jobs:

Nightly briefing. Every evening it emails both parents tomorrow's plan. For each event it shows where it is, when to leave and how long the drive takes. It also flags clashes and says which drives need the second parent.
Email to events. Forward an activity email (from a coach, school, studio and so on) to a dedicated inbox. The Pi reads it, pulls out the events and replies with one calendar invite per event. Accepting an invite in Outlook adds the event to the shared Microsoft calendar, which syncs to the Skylight.

All AI runs locally on the Pi through Ollama with a small open-weight model. Kids' names, schedules and addresses never go to a hosted LLM.

The full spec is in .scratch/family-drive-planner/spec.md, and the work…

View on GitHub

make up, make pull, then make briefing / make extract FILE=.... In DRY_RUN=true mode, every email is written to out/ instead of sent, so you can try it with no accounts at all.

How I Built It

I used Claude code to ideate and then plan the app. We broke the plan down into idividual issues that can be tested and verified in small chunks.

Ollama in a Docker container next to the app, running a small open-weight instruct model (qwen2.5:1.5b-instruct-q4_K_M, about 1 GB) that fits a Raspberry Pi 4 with 4 GB RAM.
Python: httpx, pydantic, icalendar + recurring-ical-events for the published Outlook ICS feed, dateparser, apscheduler, and SQLite for the route cache and processed Message-IDs.
OpenRouteService for drive times.

The main design rule: keep the model's job small. A 1.5B model on a Pi is great at copying text out of an email and terrible at date math, so:

For extraction, the model returns text spans only, like "next Tuesday", "5:30 pm" and "Field 3", as structured JSON. Code turns those into real dates relative to when the original email was sent, matches kids and venues against a family.yaml, and validates everything. Anything that doesn't resolve goes into a "Couldn't read" section of the reply and is never guessed.
For the briefing, code computes leave-by times, conflicts and second-driver flags. The model only writes a 2–4 sentence summary. If Ollama is down or slow, or the summary mentions a time that isn't in the plan, the email goes out with just the table.

It isn't perfect yet, and the demo run shows it. On a different day the summary said "both drives need the second parent" when the table didn't flag that. My guard only checks times, so that claim slipped through. That's exactly why the table is the source of truth and the paragraph is a nice-to-have, and it's the next thing I'm tightening.

There's also a small eval harness (make eval): 12 labeled emails, per-field accuracy for date, time, kid and location, so I can compare candidate models on the Pi itself.

Status: this is a weekend build. Both flows work end to end in dry-run mode, and there are unit tests with no network calls and a frozen "today". Still on my list: verifying live Gmail IMAP/SMTP, checking that invites land correctly in Outlook, and running the model comparison on the Pi.

Why Does Open Innovation Matter?

This project handles my kids' names, their schedules and where they'll be at what time. That's exactly the data I don't want to send to a hosted LLM.

Running an open-weight model locally means:

Nothing personal leaves the house except drive-time lookups by coordinates and the emails we were already sending.
It costs nothing to run. The Pi is already on, and there's no per-token bill for parsing every coach's newsletter.
I can swap models. make pull MODEL=... plus make eval --model ... lets me compare a couple of 1B-class models on the real hardware and pick the one that's accurate and fast enough.
It's predictable. No API changes or deprecations under me. The model I tested is the model that runs.

A bigger closed model would probably extract more cleverly. But keeping the model's job small made a tiny local model good enough, and that trade is worth it for family data.

My Agent Session

I did not install the DevRelay skills before I started so I didnt capture all the session. I did write a summary of it here:

https://github.com/jsteinshouer/herding-cats/blob/main/docs/context/2026-10-03-initial-build.md

Did I hand it over?

I am finishing up the testing in dev and have not deployed it to the Pi yet so I havent handed it over yet. It is still a WIP but should be close to done.

Building a CI/CD Workflow for my CFML/Vue.js Application

Jason Steinshouer — Fri, 03 Dec 2021 04:40:54 +0000

My Workflow

The goal of my project was to create a CI/CD workflow for a full-stack application written in CFML (Lucee) and Vue.js, running in Docker.

Here is a simplified outline of my CI workflow.

Start a database service using the MySQL Docker image
Build the Docker image for my application
Run the newly built Docker image and connect it to the MySql database service
Execute back-end API integration testing using Testbox
Execute Cypress front-end and end-to-end tests

My deployment process is triggered when a Github release is created using a semver tag. Here is the general outline.

Build a multi-platform Docker image. (I am utilizing the free trial of t4g.micro AWS EC2 instance so I need to run it on ARM64 architecture.)
Push the image to Dockerhub using a semver tag.
Connect to the server and trigger a Docker service update to pull down the new image and start it up.

Github Actions I am using

Since my application is running with Docker I am utilizing several Actions from Docker.

docker/setup-buildx-action (Buildx allows for building multi-platform images)
actions/cache (With buildx I can use Docker layer caching to speed up subsequent builds)
docker/build-push-action (This action builds the images and optionally pushes them to a repository)
docker/setup-qemu-action (This is needed for building images for other platforms)
docker/login-action (Login to Dockerhub so it can push the image)

Submission Category:

DIY Deployments

Yaml File or Link to Code

jsteinshouer / movie-list-app

My Movie App

Getting Started

Docker secrets

For development generate the secrets that docker-compose will use to to pass database credentails for our development environment.

mkdir secrets
openssl rand 20 | base64 -w 0 > ./secrets/MYSQL_ROOT_PASSWORD
openssl rand 20 | base64 -w 0 > ./secrets/MYSQL_PASSWORD
openssl rand 32 | base64 -w 0 | docker secret create JWT_SECRET -
echo "mydbuser" > ./secrets/MYSQL_USER

Environment variables

Create a .env file for your envrionment.

cp .env.example .env

OMDB API

This application uses the Open Movie Database API. You can register for a free API key at https://www.omdbapi.com/.

Set OMDB_API_KEY=<yourkeyhere> in the .env file.

Run the application using Docker Compose.

docker compose up

VS Code - Remote Container

You can also run the application using the VS code remote container extension.

Run the tests

Coldbox API Tests

You can execute the API tests in the terminal using this command.

docker exec -it movie-app-api

…

View on GitHub

CI - main.yml

CD - release.yml

Additional Resources / Info

Here are a few of the resources I used for setting up my workflows.