Clear Skies Case Study | Orbit & Explore

Slide 1 - Title

A personal go/no-go forecast for backyard astrophotography, built because the weather tools I used were useful but never quite mine.

GO

Tonight

72h

Scan

7

Nights

Live project

clearskies.jrtb.me is the real deployed app behind this case study.

Slide 2 - Context

Astrospheric gave me astronomy-specific signals, Weather.gov had authoritative local data, and Carrot Weather was fast for general checks. The pain was jumping between them, paid upsells, and a clunky interface when I only needed tonight's answer.

Actual job to be done

Answer tonight's observing decision without a tab hunt.

forecast.weather.gov

Graphical forecast for the observing location. I can show more of the page here, but the embedded site still controls its own internal scroll.

Slide 3 - Product Principle

Tell me whether the rig should go outside, stay outside through the morning, or stay packed.

GO

Worth setup.

CAUTION

One signal needs attention.

NOT OK

Keep the gear packed.

Astrophotography reality

1. Setup and polar alignment

2. Imaging session through morning

3. Flats, teardown, dew and rain risk

Slide 4 - Research

The first research pass split the forecast into practical questions: rain in the next 24 hours, cloud cover when dark, seeing guidance, moon interference, and a multi-night outlook.

Question

->

Signal

->

Decision

NWS precipitation and grid data

Open-Meteo cloud layers and model blending

Optional 7Timer seeing guidance

Moon calculations for observing context

Slide 5 - Timeline

Mar 30: CLI report. Mar 30: seven-night scope strip. Mar 31: web app, Lambda, SAM, and CloudFront. Apr 1: custom domain and live cloud map. Apr 5-6: mobile, explanations, performance, and scheduled snapshots. Apr 28: live search feed.

CLI

Web

Map

Polish

Search

Mar 30 CLI and seven-night scope strip

Mar 31 Static web app and Lambda

Apr 1 Custom domain and live cloud map

Apr 5-6 Mobile, explanations, performance, snapshots

Apr 28 GET /search-index.json

Slide 6 - Architecture

Python gathers NWS, Open-Meteo, and optional 7Timer data, blends the hourly forecast, applies scope rules, then returns browser-ready JSON.

Fetch

Blend

Gate

{
  "sources": ["NWS", "Open-Meteo", "7Timer"],
  "models": ["gfs_seamless", "ecmwf_ifs", "gfs_global", "icon_seamless"],
  "view_model": ["headline", "chart.hourly", "nearest_place", "seven_day"]
}

Slide 7 - Logic

A generic weather app says it might rain. Clear Skies says GO, CAUTION, or NOT OK for the upcoming night.

Rain through local 10:00

Clouds near sunset alignment

Wind and humidity

Moon and seeing

Conservative by design

Rain probability, precipitation rate, cloud cover, wind, humidity, moon illumination, and model seeing become thresholded signals because the cost of being wrong is wet gear.

Slide 8 - Interface

A collapsible headline, live cloud map, 72-hour chart, and next-seven-nights strip give the useful answer first and the detail only when needed.

clearskies.jrtb.me

Live app frame. If your browser blocks the embed, open clearskies.jrtb.me.

Static HTML/CSS/JS, no framework

Leaflet cloud map through Lambda proxy with NOAA GOES fallback

Collapsed daytime chart hours, metric help modal, seven-day popovers

Mobile scroll fixes and performance diagnostics tucked in the footer

Slide 9 - Infrastructure

Static files live behind S3 and CloudFront. Forecast JSON comes from a Python Lambda Function URL. EventBridge can refresh a static snapshot so first load does not always wait on live upstream APIs.

Browser

->

CloudFront

->

Lambda

SAM

CloudFormation

Route 53 + ACM

GitHub Actions OIDC

X-Astro-Cache

Server-Timing

Slide 10 - Agentic Development

I used AI agents to move through research, spikes, refactors, deployment plumbing, UI polish, and tests without losing the product judgment.

travel_explore

Research

construction

Spikes

deployed_code

Deploy

done_all

Tests

Agents accelerated implementation and exploration. The human product constraint stayed stable.

Slide 11 - Controls

The agents could suggest and implement, but the project stayed bounded by a simple rule: do not build a weather portal; build my backyard observing answer.

Constraint: one backyard, one decision, one fast answer.

Shared forecast logic instead of duplicated web rules

Snapshot tests for build_view_model

OpenWeather credentials kept server-side

Seeing is estimated rather than measured

Slide 12 - Showcase

It is small enough to finish, real enough to use, and technical enough to show product sense, backend design, frontend craft, and operational discipline.

Product

Backend

Frontend

Forecast modeling choices

Python library extraction

Lambda API routing and static UI

Map layers, accessibility labels, mobile fixes, CI, diagnostics, documentation

Slide 13 - Tradeoff

The strongest choice was keeping the app opinionated. The remaining challenge is confidence: making model agreement, freshness, and uncertainty obvious without turning the page back into a dense weather dashboard.

Confidence language still needs calibration

Worked

Fast decision, personal location, no upsell, live map, seven-night planning.

Needs work

Confidence language, calibration, moon planning, maybe an iPhone widget.

Slide 14 - Takeaway

Clear Skies turns a scattered forecast ritual into one fast, personal answer: is tonight worth setting up for astrophotography?

Scattered forecast ritual -> one backyard observing answer.

Launch Project Read Blog Post

Clear Skies

This case study deck is not supported on mobile.