DEV Community: adi-ray

EOD Report: my daily status report to the CEO, drafted by a local Gemma 4

adi-ray — Sun, 25 Oct 2026 17:49:55 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Every day before I log off, I send our CEO a status report:

how long I was on the system
what I worked on
what it changed
how long each task took from start to finish (our TAT, turnaround time)

EOD Report writes it for me. I run one command:

eod

It reads what my laptop already knows about my day, asks Gemma 4 running locally in Ollama to turn that evidence into tasks a CEO understands, and opens a small review page. I tick what's finished, fix a name if Gemma got it wrong, press Copy report, and paste a table into the email:

Task	Status	Started	TAT	Impact
Booking change audit trail	Done	22 Oct	4 days	Every booking edit now shows who changed it and when
Faster fare search for agents	Done	25 Oct	1 day	Search results load in about half the time
Legacy system migration plan	WIP · day 3	23 Oct	n/a	Bookings and wallet mapped; payments next

(Synthetic demo data. My real reports have private repo names in them.)

The person who gets to be lazier is me, at 7 pm, every working day.

What it reads

Source	What it gives the report
Git, every repo under my work folders	The work itself. A feature branch is a task, and merging it into main marks it Done automatically.
Claude Code sessions, including the VS Code extension	Work with no commits yet: investigations, debugging, deploys. My own prompts name the task.
Windows event log	When I sat down and when I stopped: sign-in, wake and sleep events, no admin rights needed.
WakaTime, optional	Today's coding time, from the CLI I already had installed.

TAT that spans days

This is the part a git-log summary can't do. A task starts on the first day it has activity. Each day I keep working on it, it shows as WIP · day N. On the day it's done, by a merge or by me ticking the box, its TAT is the days from start to done, counting both ends. Task state persists locally, so Gemma's job each evening includes "does today's work continue something that's still open?" When it does, the start date carries over and the TAT stays honest.

How I Built It

It's plain Python with zero runtime dependencies: the standard library, plus HTTP calls to Ollama on localhost.

git log ──────────────┐
Claude Code sessions ─┼─► evidence ─► Gemma 4 (Ollama) ─► task store ─► review page ─► table
Windows events ───────┘               group, name,        TAT across    127.0.0.1
                                      match open tasks    days

1. Evidence, deterministically. For each day it collects my commits across repos, skipping stashes and other people's commits. It also collects my Claude Code prompts from that day, with IDE context and skill boilerplate stripped. A session only counts if it has at least two prompts or actually edited something, so a quick question doesn't become a "task". Anything already linked to a known task (the same branch, or the same session continuing) is matched without the model.

2. Gemma 4 does the part rules can't. Commits made straight to a shared branch don't say which feature they belong to. Gemma gets the leftovers plus my open tasks and replies in strict JSON. It groups related commits and sessions into 2 to 6 tasks, names them in plain business English ("Booking change audit trail", not feat(audit): add actor col), matches continuations to open tasks, and writes a 12-word impact line for each. I call Ollama's native /api/chat with format: "json" and think: false. On my 4 GB laptop GPU it takes about a minute, which is nothing for something that runs once a day.

3. The model never gets the last word. Every reply is validated: each piece of evidence must land in exactly one task, and a match must point at a real open task. If not, the validator's complaint goes back to Gemma for one retry. If Ollama isn't running at all, it falls back to one task per branch or repo, so the report still gets written. Every row on the review page links to the commits and prompts behind it. If it's not in the evidence, it doesn't go to the CEO.

4. Time on system, honestly. My first version said I'd been active for 17 hours. Windows had woken itself at 3 am for an update, and I'd treated every wake event as "I'm at my desk". Now a wake or sign-in only counts if I actually do something within 30 minutes, only my own prompts count as signs of life (not the assistant's replies), and a 30-minute silence means I was away. The README says plainly that this is an estimate.

5. Your edits stick. Renames, merges, Done ticks and impact edits are saved. Untouched drafts are regenerated on each run, so a rough first pass never hardens into the record.

There are 23 tests: TAT maths, carrying tasks across days, auto-Done on merge, Gemma reply validation and fallback, secret redaction, the review API's read-only and CSRF rules, and the exact table layout.

Why Does Open Innovation Matter?

Look at what this tool reads: every commit message in my company's private repos, the full transcript of every conversation I've had with my coding assistant, and a log of when I sat down and walked away. I'm not sending that to a hosted API to save myself ten minutes. With an open-weight model on my own laptop, none of it leaves the machine. The review page listens on 127.0.0.1 only, a redactor masks keys and tokens before anything reaches the model, and the only thing that ever goes out is the table I paste myself.

It also costs nothing to run. A daily task forever is exactly the kind of habit a per-token bill quietly makes expensive. And because it's my model on my machine, I could tune its behaviour freely: the prompt, the JSON contract, and a validator that sends Gemma its own mistakes back. If a better open model comes out next month, switching is one environment variable: EOD_MODEL.

A closed API would have done the grouping too. I just couldn't have pointed it at this data.

The Lazy Payoff

Writing this report by hand took me 15 to 20 minutes every evening, after my working hours were already over. It wasn't the typing. It was:

recalling exactly what I had done that day, across several repos and a dozen conversations with my coding assistant
describing the thought process behind each piece
spelling out the impact of work that was already finished

In effect I was doing my day's work twice: once for real, and once again from memory for the report.

Now that recall is the machine's job, because the evidence was sitting on my laptop all along. eod gathers it, Gemma spends about a minute turning it into tasks with impact lines, and my part is a quick review: tick what's finished, fix a name if needed, copy.

A cheapest-day fare calendar for travel agents: Gemma 4 reads the supplier APIs, Chronos fills the gaps

adi-ray — Fri, 16 Oct 2026 21:58:33 +0000

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

What I Built

I build software for a travel agency that runs a B2B flight booking portal: sub-agents log in, search, and book across 13 suppliers (a GDS, low-cost carriers, NDC airlines and fixed-departure consolidators).

Watch an agent with a customer on the phone and you'll see the same thing every time:

"Is Tuesday cheaper than Wednesday?" search. "What about Thursday?" search.

Every search fans out to every supplier. It's slow for the customer, and it burns supplier quota: GDS look-to-book ratios are a real cost.

Fare Calendar answers "which day is cheapest?" before the agent searches. It's a date picker that shows the lowest fare under every date:

● seen: a real fare an agent got for that date in the last 3 days
est.: a model estimate, with a likely range, for dates nobody searched recently

It's built entirely from the portal's own server logs, so it reflects the fares our suppliers actually return to our agents, not a public metasearch.

Who pays: B2B travel agencies and booking platforms. It plugs into an existing portal as a <fare-calendar> web component, reads logs the platform already writes, and runs on the agency's own hardware.

Demo

Public demo (synthetic data): https://fare-calendar-demo.onrender.com
Production deploy: behind a sign-in page for our agents. It serves real forecasts for 557 routes and 23,626 priced dates from 114k observed fares.

The strip above the month is a fare profile, one bar per day. The cheap troughs are visible before you read a single number.
Each day shows its lowest fare. Seen fares get a dot, estimates a dotted underline, and the cheapest day is marked in magenta.
Picking a day explains it: "₹6,210, likely ₹5,340 to ₹7,270, estimated from nearby dates because nobody searched this day recently."
It works with the keyboard, in dark mode and on a phone, and everything is labelled indicative. Agents reprice live before booking.

Code

https://github.com/adi-ray/fare-calendar

Python (FastAPI, pandas), a dependency-free web component, and 60 tests. Real logs, fares and private supplier mappings are git-ignored. The repo ships only synthetic data and the public Amadeus mapping.

How I Built It

Two open-weight models do two very different jobs.

1. Gemma 4 reads the suppliers' APIs

The fares are buried in 13 different response formats: SOAP XML from a GDS, Navitaire XML, IATA NDC XML, and assorted JSON. Hand-writing 13 parsers before a deadline wasn't going to happen.

So I wrote a tiny mapping language that works the same over JSON and XML, and had Gemma 4 write the mappings:

{
  "rows": "faresAvailable{*}",
  "fields": {
    "fare": "fares[*].passengerFares[*].fareAmount",
    "origin": "meta.origin",
    "destination": "meta.destination",
    "departure_date": "meta.departure_date"
  },
  "generated_by": "gemma4 (validated on 6/6 responses)"
}

Gemma sees a shrunken sample of one response. Code, not Gemma, decides whether a mapping is good. It applies the mapping to 6 real responses and rejects it unless:

most responses produce rows
fares look like per-adult totals, not IDs or base fares
the route the agent actually searched shows up

Failures go back to Gemma as specific feedback:

'fareComponentList' does not exist under …originDestinationOptionList[*]; keys there: ['fareComponentGroupList']. did you mean 'fareComponentGroupList'? 'fareComponentList' exists further down at 'fareComponentGroupList.fareComponentList'

Gemma never touches a fare at run time. Mappings are small JSON files a human can review.

The results: Gemma (local gemma4, 7.5B Q4, via Ollama on a 4 GB laptop GPU) mapped 7 suppliers in 1–6 attempts each. Three, IndiGo, SpiceJet and an NDC carrier, didn't converge in 11 attempts, so I hand-wrote those and labelled them as hand-written. IndiGo and SpiceJet store each fare as separate charges, with discounts as positive amounts, which needed sum:charges[ChargeType!=Discount] − sum:charges[ChargeType=Discount].

What I learned getting a small model to do this reliably:

Turn thinking off. Gemma 4's thinking mode is on by default in Ollama. On my GPU it turned a 5-second answer into a 58-second one, and the answer was worse.
Watch the context window. Ollama's default context silently dropped the start of long prompts, which is where my instructions were. Every early failure looked like "Gemma ignored the spec".
Make feedback name the fix. "Check your path" got repeated mistakes. "Use ^^.segment.from" got fixed mappings.
Bend the language toward the model. Gemma kept writing field paths from the document root, so the extractor now resolves those to the row's own ancestor.

2. Chronos-Bolt fills the empty dates

Agents search a handful of dates. To fill the rest:

A lead-time model separates "which day you fly" from "how far ahead you searched", since fares climb as departure nears.
Chronos-Bolt base (open weights, zero-shot, CPU) forecasts each unsearched stretch of the calendar from the departure dates before it. Missing days are passed as gaps, not invented. Its forecast is averaged with a same-weekday baseline: the two make different mistakes, and the average beats both.
The estimate is re-priced for today's lead time and blended with older searches for that exact date.

3. Data hygiene was half the work

Placeholders. One consolidator lists some dates at ₹100 (seats on request). In a lowest-fare calendar that wins every day, and it took my backtest error to 308%. Fares under ₹500, and anything outside 0.25×–4× the route median, are now dropped and counted.
Per-leg pricing. Some carriers price connecting itineraries per leg, so a DEL→HYD→BOM search could pose as a cheap "DEL-HYD fare". Only the searched route is kept.
Group totals. Some suppliers price "2 adults" as one total, so only single-adult searches are used (85% of traffic).

4. Serving it on Render

Chronos runs where the logs live and writes a 565 KB forecasts.json. The API on Render is FastAPI plus the standard library, with no PyTorch. Two services come from one blueprint:

Public demo: synthetic data, free plan.
Private: Starter with a disk (paid with the Render credit). Agents sign in on a sign-in page with a signed session cookie, and the portal can embed it with an API key. It takes nightly uploads, and a Secret File fallback serves whichever forecast is newer.

Results (honest version)

The backtest uses 14 cutoff days (Oct 1–14). The calendar is built only from earlier logs and compared with the lowest fare agents actually got over the next two days, across 11,544 searched dates:

	seen fares only	weekday baseline	Chronos-Bolt base + baseline
searched dates with a fare shown	36%	41%	41%
error when showing a real recent fare	1.0%	1.0%	1.0%
error on estimated dates (591)	n/a	18.7%	16.2%

How I picked the forecaster (5 cutoffs, 498 estimated dates):

forecaster	error on estimated dates
weekday baseline	18.4%
Chronos-Bolt small, alone	20.1%
Chronos-Bolt base, alone	17.6%
Chronos-Bolt small + baseline	17.9%
*Chronos-Bolt base* + baseline**	15.1%

The calendar's value is mostly coverage. It puts a number on 41% of the dates agents go on to search, up from 36%, and the "seen" fares are accurate.

Estimates are rough but measurably better than the obvious baseline. My first deploy used Chronos-Bolt small, which did worse than "same weekday, last few weeks". The bigger base model, averaged with that baseline, cuts estimate error by about 13% over 14 cutoffs. One honest caveat: on a separate 5-day subset with only 63 estimated dates, the ensemble came out slightly worse (20.3% vs 19.0%). It's one month of noisy, mixed GDS and fixed-departure history, and the backtest re-runs as logs accumulate.

Why Does Open Innovation Matter?

The data can't leave. Supplier fares are negotiated rates, and supplier responses are commercially confidential. Pasting them into a hosted LLM to "help write a parser" is a non-starter. Gemma 4 runs locally, so every supplier response it read stayed on the laptop.
It costs nothing per use. Mapping a supplier is a one-off job on a 4 GB laptop GPU. Forecasts for 557 routes take a few minutes on a CPU. The deployed API needs no GPU and no AI vendor.
I could change how the model behaves. Turning thinking off, setting the context size and forcing JSON output are all switches I control. A closed API would have left me guessing why answers degraded.
Swapping models was a one-line change. When Chronos-Bolt small lost to the baseline, I tried a 4× bigger open model the same afternoon, backtested five variants on real data, and shipped the winner at no cost. No vendor pricing page, no waiting list.
No lock-in. The mappings are plain JSON, the forecaster is configurable (FARECAL_FORECASTER, FARECAL_MODEL_ID), and Gemma can be replaced by any OpenAI-compatible local server.
Open models plus deterministic checks is the pattern that worked. The model proposes, code verifies against real data. That's what made a 7.5B model trustworthy enough to touch production data.

My Agent Session

This is a curated version of the build session with Claude Code: the turning points, including the wrong turns. Local paths, the private backend's internals and real per-route fares are removed.

Fare Calendar: Gemma 4 reads the supplier APIs, Chronos fills the gaps (curated build session)

You

Week 2 theme is Side Hustle. I'm thinking of a fare-price calendar for our B2B flight booking app, so agents can see the estimated lowest fare at the time of choosing dates.

Agent

Good fit: travel agencies pay for this, and your own agents are the first users. Proposed core: an open-weight time-series model (Chronos-Bolt, Apache-2.0, CPU) learning from the agency's own fare history, so search data never goes to a third-party API. Three questions before building: where does fare history come from, which model, and API + embeddable widget or inside the existing app?

You

Our search/booking logs. Chronos-Bolt. Standalone API + embeddable widget.

Agent

Built the skeleton against a documented CSV schema with clearly labelled SYNTHETIC logs: a lead-time fixed-effects model (fares climb as departure nears), a Chronos-Bolt forecaster with a seasonal-naive baseline, a FastAPI service and a <fare-calendar> web component. Synthetic backtest: Chronos 8.5% vs baseline 10.5% MAPE.

▸ Bash python scripts/backtest.py --data data/sample_search_logs.SYNTHETIC.csv

Input

$ python scripts/backtest.py --data data/sample_search_logs.SYNTHETIC.csv

Output

overall: seasonal-naive 10.5% MAPE | chronos-bolt-small 8.5% MAPE

You

Here are the real server logs. Also: can we enter Best Use of Gemma?

Agent

The logs aren't a CSV: they're per-request folders, one per supplier call. 2,250 searches over 30 days, fanning out to 13 suppliers in different formats (GDS SOAP XML, Navitaire XML, IATA NDC XML, assorted JSON). Hand-writing 13 parsers isn't realistic before the deadline, which gives Gemma a genuine job: read a sample of each supplier's response and write the extraction mapping, run locally so negotiated supplier fares never leave the machine. Code validates every mapping against real responses.

▸ Bash count RS files per supplier (names only)

Input

$ count RS files per supplier (names only)

Output

amadeus 824, oms 1798, scoot 792, starair 774, cheapfixdeparture 688, batikair 586, indigo 579, airiq 566, aix 410, spicejet 419, emirates 251, aeroprime 94, kandhari 15

Agent

Wrote a small mapping language that works the same over JSON and XML, plus a hand-written Amadeus mapping as Gemma's worked example. First real backtest on Amadeus-only data looked promising but tiny: Chronos 4.4% vs baseline 10.4% over 18 estimated dates. I flagged it as too small to trust.

Agent

First Gemma pass mapped only 3 of 12. The failures weren't the model's fault: (1) Ollama's default ~4k context silently dropped the start of long prompts, which is where the instructions were, so Gemma answered as if it never saw them; (2) the sample-shrinker cut deep SOAP responses at depth 14; (3) retry feedback only said 'check the path'. Fixed all three: native Ollama API with a larger context, deeper samples, and feedback that says exactly where a path breaks.

▸ map_supplier (Gemma feedback) aeroprime attempt 1

Input

aeroprime attempt 1

Output

'fareComponentList' does not exist under …originDestinationOptionList[*]; keys there: ['fareComponentGroupList']. did you mean 'fareComponentGroupList'?

Agent

Gemma was generating at ~1.4 tokens/s. Measured why: Gemma 4's thinking mode is on by default in Ollama.

▸ Bash same tiny prompt, think=true vs think=false

Input

$ same tiny prompt, think=true vs think=false

Output

think=True: 58s, 248 tokens, wrong answer | think=False: 5s, 9 tokens, correct answer

Agent

More language gaps surfaced by Gemma's near-misses, each fixed and tested: {*} for fares keyed by opaque IDs (AIX), [][] lint for lists of lists (BatikAir), [-1]/[last] for the final flight leg, sum: for fares split into charges, and an automatic '^' rewrite when Gemma writes field paths from the document root. Also caught myself: a new 'base fare vs total' check flagged AIX, but AIX's fareAmount was already the per-passenger total; the bigger 'total' summed all passengers. Narrowed the check to same-passenger siblings.

Agent

With 7 suppliers mapped the backtest said 308% error on 'seen' fares, which should be near-exact. Investigated instead of reporting it: one consolidator lists some dates at ₹100 (seats on request), and a lowest-fare calendar picks that every time.

▸ Bash share of fares below 30% of route median, by supplier

Input

$ share of fares below 30% of route median, by supplier

Output

kandhari: 528 rows at ₹100 on a route whose median is tens of thousands

Fix: drop fares under ₹500 and per-route outliers outside 0.25x-4x the median, and count them. Seen-fare error back to 1.3%.

You

Rest of the suppliers need to be mapped, except OMS and Aeroprime. Try Gemma again now that RAM is free.

Agent

Gemma mapped Emirates on attempt 6. IndiGo, SpiceJet and an NDC carrier didn't converge in 11 attempts each, even though the feedback named the exact location, so I hand-wrote those and labelled them hand-written. IndiGo and SpiceJet store discounts as positive amounts, so a plain sum would add them: added item filters and signed sums.

▸ Bash count Navitaire charge types and discount signs

Input

$ count Navitaire charge types and discount signs

Output

charge types: FarePrice, Tax, Discount | discount amounts: positive 27/27

Mapping: sum:charges[ChargeType!=Discount].Amount - sum:charges[ChargeType=Discount].Amount. Also: connecting itineraries are priced per leg, so only the searched route is kept (11,195 leg rows dropped).

Agent

Honest result with 11 suppliers: coverage 17% -> 23%, but Chronos-Bolt small (20.1%) did NOT beat the weekday baseline (18.4%) on estimated dates. Put that in the README and the post rather than the earlier small-sample number.

You

Can we increase the accuracy since you downgraded to 64 because of less RAM?

Agent

Correction first: 256 -> 64 was Chronos's batch size, which doesn't change accuracy, only memory. What can help is model size and ensembling, so I measured five options on the real backtest.

▸ Bash backtest --models naive,chronos,chronos-base,ensemble,ensemble-base

Input

$ backtest --models naive,chronos,chronos-base,ensemble,ensemble-base

Output

baseline 18.4% | chronos small 20.1% | chronos base 17.6% | small+baseline 17.9% | base+baseline 15.1%

Picking the best of five on one backtest flatters the winner, so I re-checked on different cutoffs: on a 63-date subset it went the other way (20.3% vs 19.0%). Then ran all 14 cutoffs (591 estimated dates): ensemble 16.2% vs baseline 18.7%. Shipped the ensemble and reported both checks.

Agent

Deployment on Render: Chronos runs where the logs live and writes a compact forecasts.json (columnar, 1.85 MB -> 565 KB so it fits a Secret File); the API serves it with no PyTorch. A public synthetic demo plus a private service behind a login, upgraded to Starter + disk with the Render credit. Redesigned the UI: a fare profile strip above the month, the route as the headline, a panel explaining each picked day, keyboard navigation.

You

The private site shows the browser's sign-in popup, and cancelling it shows raw JSON. The route dropdown opens with giant faint text.

Agent

Replaced Basic-auth popups with a sign-in page and a signed, HttpOnly, SameSite=Lax session cookie; API calls without credentials get 401 JSON without the popup header; pages redirect to /login with same-site-only next targets. Tests cover open redirects, forged cookies and script injection via next. The headline codes stay large while an invisible native select sits on top, so the list opens at normal size in theme colours.

▸ Bash pytest -q

Input

$ pytest -q

Output

60 passed

My First User

During beta testing, our ops team switched Fare Calendar on for a few of our agents and some of our own staff.

They liked it, and they told our tech team it’s one of the features most in demand from our clients and agents. They’d been asking for something like this.

Prize Categories

Best Use of Gemma: Gemma 4, run locally, writes the supplier mappings that the whole pipeline depends on (7 of 11), verified by code against real responses.
Best Use of Render: two services from one blueprint. A public demo on the free plan, and a private Starter service with a persistent disk for nightly forecast uploads, behind a sign-in page.

What shaped the approach: "The Fare Observation Schema I'd Build Before a Flight Scraper" by arritola92 is why "seen" and "estimate" are kept apart and nothing is presented as bookable. "Chronos vs Toto: Zero-Shot Forecasting Benchmark Results" by Team Parseable is why I tried a zero-shot forecaster before training anything. "I priced 150 flights across November…" by ishemah matched the weekday effects I built the synthetic demo around.

Built with an AI coding agent (Claude Code) and reviewed by me. The product itself runs on open-weight models: Gemma 4 and Chronos-Bolt.

Trip Buddy — I built my friend a budget trip planner on an open-weight model

adi-ray — Sun, 04 Oct 2026 17:20:33 +0000

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

What I Built

MY FRIENDS loves to travel but plans trips the hard way: one tab for trains, five for hostels, a dozen blog posts listing "top 10 things to do", and a mental map that never quite fits into the days available. They're heading to Manali next month with three days and a student budget."

Trip Buddy turns that into one form. Enter where you're starting, where you're going, how many days, a budget, and what you're into. You get:

Getting there: train / bus / flight options from your city, cheapest first, with rough costs
Where to stay cheaply: three affordable areas with nightly price ranges and why each one works
Getting around: local transport options and what they cost
What to see, in what order: the famous sights grouped into days by geography, each day routed as a loop from where you're staying, with start times, travel minutes, and a lunch break, all on a map

How I Built It

The key decision: the LLM researches, plain code optimises.

form ──► /api/plan ──┬─► open-weight LLM (Llama 3.3 70B, OpenAI-compatible API)
                     │     → transport, stays, sights with coordinates (strict JSON)
                     ├─► OpenStreetMap Nominatim
                     │     → real coordinates for the destination
                     └─► optimize.js (no AI)
                           priority-select within the time budget
                           → k-means into days → nearest-neighbour + 2-opt per day
                           → timed schedule

Research (open-weight model). One call to Llama 3.3 70B returns structured JSON: transport options, budget stays with coordinates, 10–16 attractions with coordinates, realistic time-on-site, must-see flags, entry fees and best time to visit. Temperature is low, and the prompt asks for price ranges, never exact prices.
Grounding (OpenStreetMap). Models sometimes place things in the wrong city. I geocode the destination with Nominatim and drop any "attraction" more than 80 km away. In testing, a stray "Taj Mahal" in a Jaipur plan was filtered out.
Optimisation (deterministic code). Asking an LLM to "order these optimally" gives a plausible-looking but unverifiable answer. So optimize.js:
- picks sights by priority (must-sees first) until the day budget is full
- clusters them into days with k-means (farthest-point init, so it's deterministic), then rebalances overloaded days
- routes each day as a loop from the stay: nearest-neighbour, then 2-opt
- converts that into a timed schedule with travel estimates and lunch

In my Jaipur test, Amber Fort, Jaigarh Fort and Nahargarh landed on one day, and City Palace, Jantar Mantar and Hawa Mahal (a few hundred metres apart) on another. That's what a local would tell you.

Frontend. One HTML page with Leaflet and OpenStreetMap tiles. Each day gets its own colour on the map.

No npm dependencies: Node's built-in http and fetch, plus 7 unit tests with node:test.

Why Does Open Innovation Matter?

I can swap the brain in two lines. The app speaks the OpenAI-compatible protocol, so Llama on Groq, Qwen on OpenRouter, or a model on my own laptop through Ollama all work by changing LLM_BASE_URL and LLM_MODEL. No vendor lock-in for a tool I'm handing to a friend.
It costs my friend nothing. Open-weight models on free inference tiers, OpenStreetMap for maps and geocoding, no paid map SDK. A student trip planner shouldn't need a credit card.
It can go fully offline and private. Point it at Ollama and the trip plan (where you're going, when, and your budget) never leaves the laptop.
Open data keeps the model honest. OpenStreetMap lets me check the model's coordinates against real geography for free. That's why the itinerary is grounded instead of just sounding right.
I control the behaviour, not a black box. The parts that must be correct (what fits in a day, what order to go in) are code I can read, test and fix. The open model does what it's good at: knowing that Jaipur has a ₹300 composite ticket and that you should hit Amber Fort before the heat.

How I Worked

I built this with Claude Code, from idea to tested app in one sitting.

AI Disclosure

Code and this write-up were produced with help from an AI coding agent (Claude Code), reviewed and tested by me. Trip Buddy itself runs on an open-weight model (Llama 3.3 70B).

Building a Stone Paper Scissors Game with Amazon Q CLI: A Step-by-Step Guide

adi-ray — Sat, 31 May 2025 19:10:00 +0000

Overview

This blog walks you through the development of a Stone Paper Scissors game built using Amazon Q CLI, an AI-powered coding assistant that made development faster, smoother, and more enjoyable.

I chose this project because it's a fun and simple way to learn Python, explore clean code architecture, and test the power of Amazon Q CLI in an interactive development environment.

By the end of this blog, you'll learn:

How to install and configure Amazon Q CLI
How to iteratively build a Python game using AI-generated suggestions
How Amazon Q simplifies testing, debugging, and structuring code

Project Setup & Development

Setting Up Amazon Q CLI

Prerequisites

An AWS account
A working Python environment
WSL (for Windows users)

Installation Steps

For Windows Users (WSL Setup):

wsl -d Ubuntu

💡 If you get WSL_E_DISTRO_NOT_FOUND, the below command will install Ubuntu distribution

wsl --install -d Ubuntu

🔗 I referred to this guide for installing Amazon Q CLI on Windows

Start chatting with Amazon Q:

q chat

Planning the Game

I first outlined the core requirements:

Player vs Computer gameplay
Score tracking
Replay option
Clean terminal UI with color support

Then, I structured the project with the following folders:

project-root/
│
├── src/
│   ├── game_engine.py
│   ├── utils.py
│   └── run_game.py
│
├── assets/
│   └── ascii_art.txt

Building with Amazon Q CLI

Initial Prompt

I started by asking:

"Help me create a stone paper scissors game in Python with a clean architecture.
AI Prompt: Stone-Paper-Scissors with Pixel Art & 8-Bit Music

Target Library: PyGame (with Pyganim for pixel animations)

Style: Retro arcade vibe, dynamic AI, and special moves"

Amazon Q provided a basic structure with separate functions for input handling, logic, and scoring.

Iterative Development

I used follow-up prompts like:

"Add colorful terminal output to the game"
"Implement score tracking functionality"

Amazon Q responded with helpful suggestions using libraries like colorama and added features step-by-step, reducing manual effort.

Key Code Components

Some valuable code snippets from Q included:

A score dictionary to track wins
A function for randomized computer moves
A clean game loop with replay options

I refined variable names, added error handling, and tweaked color schemes for better UX.

Testing & Debugging with Amazon Q

Whenever I faced errors (like input mismatches or color issues), I simply asked:

"Fix this ValueError when input is invalid"

"Add unit tests for the game logic"

Amazon Q provided clear fixes and even mocked input() for testable functions.

Deployment

Running the Game

To play the game, simply run:

python src/run_game.py

You'll see:

Colorful prompts
Real-time score updates
ASCII visuals (from assets/)

Screenshots

Click the image above to watch the gameplay demo on YouTube

Lessons Learned

Pros of Using Amazon Q CLI

Super-fast prototyping
Clean, modular code generation
Helpful debugging prompts
Smart suggestions for best practices

Tips for Others

Break down tasks into short prompts
Use follow-ups to refine code
Always test generated code manually

Conclusion

This project demonstrated how Amazon Q CLI can accelerate even small projects like games while encouraging clean architecture and modular design.

If you’re learning Python or want to prototype apps efficiently, give Amazon Q CLI a try!

Resources

🎥 Gameplay Demo Video
🔗 GitHub Repository – Stone Paper Scissors Game
📘 Amazon Q CLI Documentation

🛰How AI Helped Chandrayaan-3 Achieve Its Lunar Mission? 💡🚀 📡

adi-ray — Thu, 24 Aug 2023 14:54:22 +0000

ISRO’s Chandrayaan-3, the third lunar mission has set history by touching down on moon’s surface.

ISRO, or the Indian Space Research Organisation, has pioneered space exploration by launching everything from small satellites to big moon missions. This demonstration of India's technological prowess has helped to establish the country's flag in the international space landscape.

Chandrayaan-3: A Giant Leap to the Moon's South Pole

Chandrayaan-3, the successor to Chandrayaan-2, represents the pinnacle of India's space technology. This lunar mission aims to soft-land a rover near the Moon's south pole. This achievement could catapult India's space industry to unprecedented heights and inspire future generations to reach for the stars. By integrating AI, ISRO joins the global space community in its quest to tap into this technology's potential to unearth cosmic truths.

During the last stage of its landing, the Chandrayaan-3 spacecraft has gone through a window of "17 minutes of terror", where it was carrying out a series of maneuvers which was crucial for landing. It included altitude adjustments, firing thrusters, & scanning the surface for any obstacles - all of that was done with the help of AI. During this period, the Chandrayaan-3 team was able to monitor its progress from the ISRO Telemetry, Tracking, & Command Network in Bengaluru, while Al was at the helm of the Vikram lander. ISRO has already confirmed that the lander used autonomously controlled by Al using Machine Learning that operated its guidance, navigation, control & other systems.

Artificial Intelligence: Guiding the Lunar Rover

At the core of this mission is the pivotal role of Artificial Intelligence (AI). Lander & rover, as well as entire ship is designed & developed using AI, The spacecraft’s design is being optimized for weight, performance, and safety using AI algorithms.
It uses this tech to examine lunar soil, identify obstacles, and send priceless data back to Earth. Built to operate for a lunar day, the rover's AI-driven abilities could broaden our understanding of the lunar surface, atmosphere, and possible water existence.

Artificial Intelligence Reshaping the Space Industry

Given the vast and unpredictable expanse of space, AI's problem-solving and data-analysis abilities can be crucial. AI can help make critical real-time choices, eliminate human errors, and improve overall mission performance.
As we look to the future, the intersection of AI and space exploration promises to push the boundaries of what we thought was possible. AI might become a vital tool for everything from forecasting mission abnormalities to identifying new celestial bodies and potentially organizing interstellar communities.

So, Chandrayaan-3's significance goes beyond its scientific goals. It symbolizes the merging of AI and space exploration, opening a new era where both will jointly fuel our quest to decipher the universe.

     Space technology in the Service of humankind.

Feel free to share this article with your peers and do hit a ❤️ if you liked it. If you have any query, feel free to ask them in the comment section.

You can also connect with me on LinkedIn

Introduction to APIs via Postman

adi-ray — Sun, 12 Mar 2023 13:42:37 +0000

Recently, I had the pleasure of attending an "API 101 with Postman" session. As a newcomer to the world of APIs, I was eager to learn about Postman's capabilities and how it can streamline the API testing and development process. In this blog post, I'll share my experience attending the session and provide a comprehensive overview of Postman API.

About the speaker:
The session was conducted by Divyansh Pratap Singh, who has an extensive experience in API testing and automation.

Agenda of the session:

Intro to APIs and Postman .
Requests and responses.
Hands-on session.
Follow-up resources.

What's an API ?

Software has become more complex and collaborative over the years. Developers no longer need to create every services from scratch.
Application Programming Interfaces(APIs) allow developers to access data from a service (like Google or twitter) without any kowledge of how the codebase has been implemented.

APIs allow services to communicate with each other.

Types of APIs:

Hardware APIs
Software Library APIs
Web APIs

Request-Response Pattern

What is Postman?

Postman is a collaborative API development platform that simplifies creating, using and testing APIs with an interactive UI.

More than 500,000 organizations & 13 million developers use Postman.

One of the main reasons for the increased Popularity of the Postman is because of its interface :

Refer this link for simply creating your postman account.

Making Requests (Interact with the API) :

We were then shown how to send requests to APIs using different HTTP methods, such as GET, POST, PUT, and DELETE.
The 3 ingredients to make a request:

Methods (GET,POST,etc.)
Address / Endpoint (URL)
Path

The response elements for Receiving Requests are :

Status Codes (200 OK , 201 CREATED , 404 NOT FOUND)
Headers
Accessing body data

Resources

Learning Center
API Network
Forum

Attending the Introduction to Postman API session was a great learning experience. We learned about the basics of API with Postman and got hands-on experience with various features of the tool.

Apart from this, we also got to know about the Postman Student Expert Certification which will help us take Postman skills to the next level and showcase our expertise to the world.

Click Here to explore more about Postman Student Programs.

Feel free to share this article with your peers and do hit a ❤️ if you liked my blog. If you have any query about how to get started with Postman , feel free to ask them in the comment section.

You can also connect with me on LinkedIn