CloudDeck

The problem

A raw METAR is a dense string of codes:

KDAL 141953Z 18012G20KT 10SM FEW045 SCT250 33/19 A2991

Every pilot learns to read it, but reading it is not the same as deciding with it. The questions that matter are: is this VFR? Which runway favors the wind? How much crosswind will I actually have on landing? Answering those means decoding the string and then doing trigonometry, on the ramp, usually in a hurry.

What I built

CloudDeck fetches the current observation for any ICAO identifier from the FAA Aviation Weather REST API and answers those three questions directly.

Flight category is derived from ceiling and visibility and shown as a color-coded indicator — VFR, MVFR, IFR, LIFR — so the go/no-go read is immediate rather than inferred.

Runway sorting ranks the available runways by how well each aligns with the reported wind, putting the favored runway first.

Crosswind and headwind components are resolved from the angular difference between wind direction and runway heading:

crosswind = windSpeed × sin(θ)
headwind  = windSpeed × cos(θ)

where θ is the angle between the wind and the runway centerline. A negative headwind is a tailwind, and CloudDeck labels it as such — that sign is exactly the detail a tired pilot misreads.

Engineering notes

The API client is separated from the JavaFX view. Parsing a METAR is pure, deterministic logic over a string, and keeping it independent of the UI made it testable without standing up a window or hitting the network.

Maven handles the build so the project compiles the same way on any machine, which matters for something meant to be handed to another pilot rather than demoed once.

What I would change next

I would package signed installers, add a dependable runway-data source, and surface the age of every observation more prominently. I would also add contract tests around the FAA response shape so an upstream API change becomes a clear build failure instead of a pilot seeing incomplete weather.