DEV Community: Arnulfo

Ventana seca: finding the dry hour to get outside in Panama's rainy season, with Gemma on my laptop

Arnulfo — Wed, 07 Oct 2026 02:08:46 +0000

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

What I Built

October is the heart of the rainy season in Panama City. Most afternoons, the sky opens up somewhere between 1 and 5 p.m. A weather app gives me a percentage for every hour and leaves the decision to me, so I end up checking the screen over and over, or I just stay inside.

Ventana seca ("dry window") answers one question: when today can I be outside without getting soaked or cooked?

I don't have a free weekday morning for a trail. My chance to be outside is my daily route: on foot near Plaza 5 de Mayo at 7:30 a.m., arriving in Costa del Este at 8:00, lunch at noon, heading out at 4:00. So the main mode takes that route, checks the forecast for each stop, and tells me which stop is worth spending time outdoors, plus what to carry for the whole day. On weekends, a second mode looks for the best window at a park like the Parque Natural Metropolitano or the Cinta Costera.

You run one command in the morning, read one card, and optionally save a calendar event that alerts you 30 minutes before. Then the phone goes back in your pocket. The screen should be the shortest part of the experience.

Demo

This is my real route for Tuesday, October 6, with the real forecast and Gemma choosing on my laptop:

The 7:30 and 8:00 stops look dry (20% and 18%). Noon brings a 66% chance of rain with a 39 °C heat index, and 4:00 p.m. is at 88%. Gemma picks 8:00 a.m. in Costa del Este, and the raincoat goes on the list from the morning because of the afternoon.

Here is the same route when I write, in my own words, that I want to walk during lunch:

Gemma respects the time I asked for and warns me about the rain and heat. The red Ojo ("heads up") line is not written by the model. The code adds it whenever the chosen window scores poorly. I'll explain why below.

Watch the 31-second demo video. It has no narration and shows the command and the resulting card for three scenes. The interface is in Spanish, because the people I built it for speak Spanish.

Code

yosef7 / ventana-seca

Find the rain-free window to go outside in Panama City, chosen by Gemma running locally. DEV Hacktoberfest 2026 · Week 1: Touch Grass

Ventana seca

En octubre llueve en Ciudad de Panamá casi todas las tardes. Ventana seca mira el pronóstico por hora de los próximos días, calcula los tramos de luz con menos lluvia, calor y sol fuerte para salir a caminar o correr, y deja que Gemma, un modelo de pesos abiertos que corre en tu propio equipo con Ollama, escoja uno según lo que tú le pidas. El resultado es una tarjeta de un vistazo y un recordatorio en el calendario que avisa media hora antes, para que guardes el teléfono y salgas.

In English. Ventana seca ("dry window") finds the best rain-free window to go outside in Panama City during the rainy season. It scores hourly forecasts from Open-Meteo, lets Google's open-weight Gemma model, running locally through Ollama, pick one of those windows based on what you ask for in plain words, and writes a one-glance card plus…

View on GitHub

MIT license, Python standard library only (plus pytest for the 25 tests). Setup:

git clone https://github.com/yosef7/ventana-seca.git
cd ventana-seca
uv sync
ollama pull gemma4:e2b
uv run python -m ventana_seca --ruta "7:30 5 de mayo, 8:00 costa del este, 12 pm costa del este, 4 pm costa del este"

The route is saved, so the next mornings it's just uv run python -m ventana_seca --mi-ruta.

How I Built It

The split: code calculates, the model interprets. Numbers are where a small model is most likely to slip, so the code handles all of them:

Forecast. Ventana seca asks Open-Meteo for hourly rain probability, millimeters, heat index, UV and daylight. It asks for the coordinates of the place (a park, a plaza), never mine, and keeps a local copy so it still works without signal.
Scoring, no AI. Each window starts at 100 points and loses points for rain probability, expected millimeters, heat index above 32 °C and UV above 7. The code keeps up to five daylight windows, at most two per day and at least three hours apart, so there are real alternatives (morning vs. late afternoon). In route mode, each stop of my day is a candidate.
Choice, with Gemma. Gemma 4 E2B runs locally through Ollama (the 4.6 GB Q4_K_M build, on a MacBook with 8 GB of RAM). It receives the candidates with their forecast and whatever I wrote: "quiero caminar en la hora del almuerzo", "voy con mi hija de 6 años, que no aguanta el calor". Its reply is constrained with Ollama's structured output: a JSON Schema whose ventana field only accepts the labels of the computed windows, and whose llevar (things to carry) field only accepts items from a closed list.
Validation and fallback. If Ollama isn't running, or the answer is invalid, a fixed rule picks the highest score. The tool always answers.
Non-negotiables in code. Water always; raincoat at 30% rain or more; cap and sunscreen at UV 6+; repellent on forest trails; a flashlight if the window touches darkness. In route mode they're computed for the whole day.

What testing with the real forecast taught me. The first version worked, and then the real runs showed me five problems. Each one changed the design:

What I saw	What I changed
With Gemma 4's thinking mode on, a choice took 38 to 114 seconds	Picking among five options doesn't need long reasoning: `think: false` brought it down to 7–9 seconds
Gemma called a 53% chance of rain "poca probabilidad" (low probability)	The code now adds the Ojo line for any window scoring under 60, whatever the model says
Gemma wrote "la opción B" in its explanation, a letter the card never shows	Gemma now chooses among readable labels like "mar 6 oct, 12:00 p. m. en Costa del Este", so there's no internal code to leak
Asked for lunch, it picked 8:00 a.m. without saying why it rejected noon	New instruction: if the requested time exists, honor it and warn clearly
It offered 7:00–8:00 and 8:00–9:00 as different options	Windows on the same day must be three hours apart

The pattern I ended up with: the model is good at understanding what I want, and the code is in charge of the facts and the safety warnings. Every number on the card comes from the forecast, never from the model.

The full list of decisions is in docs/arquitectura.md, and every test run is in docs/validacion.md.

Taking It Outside

On Tuesday, October 6, I followed my usual route with the card from the demo above. Here is the forecast next to what actually happened:

Stop	Forecast	What happened
7:30 a.m. · Plaza 5 de Mayo	20% · 31 °C · dry	Dry
8:00 a.m. · Costa del Este	18% · 31 °C · dry	Dry under a gray sky
12:00 p.m. · Costa del Este	66% · 39 °C · rain and heat	It rained
4:00 p.m. · Costa del Este	88% · 31 °C · rain	It rained

The day went the way the card said it would. The stop Gemma picked, 8:00 a.m. in Costa del Este, was dry. I took this photo at 8:15:

Then noon arrived as forecast. At 12:43 p.m., through a window in Costa del Este, the rain was streaking the glass and the hills in the distance had disappeared:

The raincoat, which the card put on the list in the morning because of the afternoon, was needed twice. At 5:52 p.m. the pavement was still wet:

One honest detail: when I checked Open-Meteo's hourly record for the same coordinates that night, it showed the storm between 11 a.m. and 1 p.m. (8.3 mm at noon) and 0 mm at 4 p.m., even though I saw rain in the afternoon. The record is a model estimate for a grid cell several kilometers wide, and a local afternoon shower can fall outside it. The full comparison is in docs/validacion.md.

Why Does Open Innovation Matter?

What I write about my day stays on my laptop. The preference text can be personal: when you leave work, who you're going out with. The saved route is literally my daily location pattern. With Gemma running locally, none of that goes to a server. The only request that leaves the computer is the forecast, and it carries the coordinates of a public place, not my GPS, with no account and no API key.

It costs nothing to run every morning. No per-request fee, no quota, no subscription. That matters for a tool you're supposed to use daily.

I could see and change how the model behaves. Because the model and the runtime are open, I measured the thinking mode, turned it off, and constrained the output with a schema. When the model softened a 53% rain chance, I could build a guardrail around its exact behavior instead of hoping a hosted API wouldn't change under me. The model is also swappable with --modelo, for example gemma4:e4b on a machine with more memory.

It works where the signal doesn't. Gemma doesn't need the internet, and the forecast is cached. On a trail with no coverage, the card still comes from the last forecast and says when it was saved.

To be honest about the trade-off: a large hosted model would probably write nicer explanations. But this job needed control and privacy more than eloquence, and the small model's mistakes are exactly the kind the code can catch.

Prize Categories

Best Use of Gemma. Gemma 4 E2B, running locally with Ollama, is the decision-maker at the core of Ventana seca. It interprets a free-text preference, chooses among computed windows through a constrained JSON Schema, and writes the explanation on the card. Its behavior shaped the design: thinking mode off for speed, readable labels instead of letters, and a code-side warning when it understates risk.

AI assistance disclosure: I built Ventana seca with Claude Code (Claude Opus 5.5) as my coding agent: it implemented the code, tests and documentation, generated the demo, and drafted this post from my route and the recorded test results. I picked the idea, supplied my real route, reviewed the results and tested it on my own commute.

Sendero: a local catechesis record with open AI for a chapel community in San Miguelito, Panama

Arnulfo — Sun, 04 Oct 2026 14:51:26 +0000

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

What I Built

Sendero is a catechesis record built for the community of the Capilla Nuestra Señora de Lourdes in Valle de Urraca, San Miguelito, Panama. The chapel's catechists accompany children through several stages of formation, and they need one reliable place to record each child's journey: enrollment, attendance, the formation received, the requirements met, and each change of stage.

Sendero turns that record into preparation for the next meeting. Its Spanish interface brings together periods, groups, participant profiles, multiple responsible adults, attendance, observations, stage requirements and a chronological history.

The open AI feature is at the start of each child's page: Preparar acompañamiento. An open-weight model selects and prioritizes two or three reviewed preparation actions and a question for the child's responsible adult, using the current requirement states and attendance counts. The proposal is saved with its model and evidence snapshot. If the record changes, Sendero marks it outdated.

The catechesis team can create a dated period and its groups, enroll a participant with multiple responsible adults, record attendance and class topics under that enrollment, and consult the complete history. Existing profiles survive the schema upgrade; new enrollments do not duplicate the participant. A catechist can mark a current AI proposal as reviewed, which records the review without changing requirements or stages.

The goal is deliberately modest: help the team arrive at the next meeting knowing what to review, while every decision about a child's progress remains with the catechists.

Sendero is intended to be handed over to the chapel community. So far I have tested the working prototype with fictional records only. Reviewing the actual stage names and requirements with the catechesis team is the next acceptance step; I do not yet have their feedback to report.

Demo

Watch the 49-second demonstration.

The recording shows the complete workflow: login with a fictional demo code, period and group creation, a participant with two responsible adults, attendance and a class topic, an observation, a real local model proposal, human review, and persistence after reload. All displayed records are fictional. The application is in Spanish; the video has no narration, and the wait while the local model generates its proposal is shown in real time.

Code

Source code, setup instructions and MIT license.

The model has its own license: the Qwen2.5-Coder-3B-Instruct model card identifies it as qwen-research. The application's MIT license does not change those model terms.

How I Built It

The application uses Python, Flask, SQLite, plain JavaScript and Ollama. I chose the available local qwen2.5-coder:3b model for the prototype and kept the adapter configurable through OLLAMA_MODEL.

The modules separate the interface, HTTP API, formation rules, persistence and local inference. SQLite foreign keys and transactions keep the records consistent; stage advancement also checks the expected current stage to reject a repeated transition. Versioned migrations add saved AI proposals, periods, groups, enrollments, responsible adults and human review without replacing existing child records. An invalid initial enrollment rolls back the entire new profile. Attendance must belong to the participant and fall within the enrollment period.

The model receives a small context: numbered requirements and their completion states, recorded-class and attendance counts, the current stage identifier and whether another stage exists. Names, contacts, class topics and free-text observations stay out of the model request.

My first free-text generation was structurally valid but suggested details not supported by the record. I changed the design: the JSON Schema supplies an allowed catalog of actions and questions, and the server validates membership and rejects duplicate actions before saving. The model can choose and prioritize within that catalog; it cannot introduce a new requirement through its response.

That is a deliberate limit on generative freedom. Sendero never treats AI output as proof that a requirement is complete, and the model has no tools to write to the formation record.

The expanded workflow passes 26 automated tests. The final Chromium run completed login, period and group creation, enrollment with two responsible adults, attendance and topic entry, local inference, review, reload and a mobile contact edit with zero JavaScript errors. Four views at both 390 and 320 pixels had no horizontal overflow. Those are emulated mobile checks, not a test on a physical phone.

In the recorded run, the real Ollama request returned a valid proposal in 17.79 seconds, with the model not yet loaded in memory; an earlier run with the model already loaded took 3.34 seconds. These observations describe this machine and those requests, not a performance guarantee. The browser validation records the final checks. The previous three-case evaluation remains available as evidence from the earlier prototype.

The implementation follows Ollama’s structured-output contract. The earlier structural-validation approach was informed by DevShakib's article on structured output and Mukunda Katta's explanation of rule-based output validation. A valid response is still a proposal for the catechists to review, not a guarantee that its priorities are useful.

Why Does Open Innovation Matter?

This project concerns children, so local operation is a practical design choice. Once the dependencies and model are downloaded, recording and inference can run without an external inference service, a subscription or a paid API key. A parish community can keep its own records on its own computer, and the AI request carries only numerical progress information that never leaves that machine.

Open local inference also let me inspect the request, change the response contract after an unsatisfactory result, and repeat the experiment. The community can try a different local model through the same adapter, respecting its license, without rewriting the registration and formation modules. I have not fine-tuned the model or claimed that this is impossible with every closed API.

The current version runs on one trusted computer with a single shared access code. It includes local access protection, a downloadable SQLite backup and printable records. Individual accounts for each catechist, retention and consent procedures, testing on a physical phone and acceptance testing with the catechesis team remain future work. The demonstration uses fictional data throughout.

AI assistance disclosure: I used Codex to help implement, test and document Sendero, and to draft this article from the stated need and recorded validation results. I used Claude Code to revise the article and documentation for the community-focused version and to re-record the demonstration.