Building a Simple Date-wise Results Lookup: Lessons from a Lottery Archive

vikram shetty — Thu, 22 Oct 2026 05:36:22 +0000

A date-wise results archive is one of the simplest useful datasets you can publish. Each record answers a narrow question: what came out, and when? While working on a lottery archive, I settled on a small, flat structure that is easy to reason about.

Structure of the archive

Every entry has four parts: the date, the draw time (1 PM, 6 PM or 8 PM), the series, and the number. The date plus draw time forms a natural key, since only one result exists per slot. Series and number are stored as separate fields, but the full ticket is also kept as one normalized string such as "63A 12345".

{ "date": "2026-10-21", "draw": "6PM", "series": "63A", "number": "12345" }

Grouping by date, then by draw time, gives a page layout that mirrors how people think: pick a day, see up to three draws.

Exact match beats partial match

It is tempting to let users type a few digits and show everything that looks similar. For results data, that backfires. A ticket is either a winner or it is not, and fuzzy matching creates false positives that look like wins. Exact match on the full ticket (series plus number) gives a single, unambiguous answer, and it is trivial to index: a hash lookup, no scoring, no ranking.

My rule: normalize input (trim, uppercase, collapse spaces), then compare the whole string. If nothing matches, say so plainly.

Keep it static and fast

Past results never change, so the archive is a perfect fit for static generation. Pre-render one page per date, serve it from a CDN, and keep client-side JavaScript minimal. For lookup, ship a small JSON index per month and fetch only what is needed. No database, no server round trips, and almost nothing to break.

For a real-world example of this layout, see the Dear Lottery past results chart.

Takeaways

Use date plus draw time as the key.
Store a normalized full ticket for exact matching.
Prefer static pages and small indexes over dynamic backends.

Simple data deserves a simple architecture.

I Used an AI Assistant on My Phone as a Dev Tool for a Month. Here's the Honest Verdict.

vikram shetty — Sun, 11 Oct 2026 06:55:12 +0000

I've been coding for long enough to remember when "mobile development environment" meant SSH-ing into a server from a phone with a keyboard the size of a postage stamp. So when AI assistants started shipping proper phone apps, I was sceptical. I tried using one as my main "away from desk" dev tool for a month.

Here's what actually worked, what didn't, and where I think this is heading.

What worked

Rubber-ducking on the go. Nine times out of ten, the bug I'm stuck on isn't a typing problem. It's a thinking problem. Explaining it out loud to an assistant on a walk solved more issues than I'd like to admit. The duck has finally learned to talk back.

Reading unfamiliar code. Pasting a gnarly function and asking "what does this actually do, step by step" is genuinely useful on a small screen. You don't need an IDE to understand something.

Drafting tickets and PR descriptions. I'd dictate the rough idea, get a clean draft back, and tidy it later at my desk. Saved me maybe 20 minutes a day.

What didn't

Writing real code. Anything longer than ~30 lines on a phone is still miserable, AI or not. Reviewing a diff on a 6-inch screen is how bugs get shipped.

Context. The assistant doesn't know your codebase unless you feed it. On mobile, feeding it is the hard part.

Trust. It's confidently wrong sometimes. Rule of thumb: never merge anything you couldn't explain to a colleague.

Where it's heading

The interesting shift isn't chat. It's agents that can take actions on your phone, not just answer questions. I read a decent non-hype breakdown of what a Claude AI agent on a phone could actually change, and it matches what I saw: useful for small, well-defined tasks, not a replacement for sitting down and building.

There's also a good plain-English piece on how the Claude mobile app changes everyday AI access if you want the non-developer angle to send to a manager who keeps asking "should we be using this?"

My setup now

Phone: thinking, reading code, drafting text.
Laptop: anything that touches a real repo.
Rule: if I catch myself writing a for-loop on my phone, I put the phone down and go for the walk I was supposed to be on.

Curious how others use AI on mobile. Is it part of your workflow, or still a novelty?

I keep up with this stuff mostly through plain-English explainers on GenzHunt, which covers trending tech without the launch-day hype.

DEV Community: vikram shetty