DEV Community: owen

I built a tool that turns aurora data into a single decision: GO, MAYBE, or NO

owen — Fri, 28 Aug 2026 03:47:14 +0000

Every time a geomagnetic storm makes the news, the same thing happens in my household: someone asks "can we see the northern lights tonight?", and I open three tabs — a Kp index chart, a cloud forecast, and a light pollution map — and still can't give a straight answer.

The existing aurora tools are built by and for space-weather people. They show you the raw data: planetary K-index, aurora oval plots, solar wind speed. That's great if you know what "Bz = -12 nT" means for your driveway. Most people don't. Some sites go the other way and print invented precision like "73% chance of aurora tonight" — a number nobody can honestly produce.

So I built Aurora Tonight (aurora-tonight.com): enter your city or ZIP, get one of four answers — GO, MAYBE, NO, or UNKNOWN — plus the best viewing window, the main obstacle in plain language, and which direction to look.

The stack

Nothing exotic, and that was the point:

Next.js on Vercel. Forecast pages are served via ISR — the answer for a given city only changes as fast as the upstream data does, so per-request rendering was just burning invocations for identical bytes.
NOAA's aurora oval data for geomagnetic activity. This is the authoritative public source; I deliberately don't layer a proprietary "prediction" on top of it.
Open-Meteo for cloud cover snapshots. Clouds are the #1 reason a strong geomagnetic night is still a NO, and most aurora sites ignore them entirely.
Darkness, moonlight, and light pollution are computed or looked up server-side. Everything is cached at the edge; the whole site is static-ish and free to run, which is why the tool can be free with no signup.

The interesting design decision: what not to compute

The hardest part wasn't the data pipeline — it was deciding the output contract. Three rules I ended up with:

No fake percentages. The model's output is a categorical call, not a probability. If you can't defend "73%", don't print it. GO / MAYBE / NO maps to what a person actually does with the answer.
UNKNOWN is a first-class state. If the cached data snapshot is stale, the page says UNKNOWN instead of extrapolating a confident-looking guess from old data. This costs us some "always has an answer" slickness, and it's worth it.
The main obstacle is part of the answer. "NO" alone is useless. "NO — overcast until after 1am" tells you whether to set an alarm.

I wrote up the full scoring logic on the methodology page if you're curious how the calls are made — it documents exactly what goes into a GO versus a MAYBE.

Current scope and honest limitations

It covers 15+ indexed US states and cities — Fairbanks and Alaska down through mid-latitude places like Colorado, Ohio, and Chicago, where aurora is a rare-event question rather than a nightly one. Northern hemisphere, mid-to-high latitudes only. It won't tell you anything useful in Texas, and it says so.

If you're building anything in the "raw public data → plain-language decision" space, I'd genuinely like to hear how you handled the honesty-vs-slickness tradeoff. The temptation to print a number that looks more confident than the data deserves is real.

I built a roof calculator that does all the math in your browser — no server, no signup, no lead form

owen — Fri, 28 Aug 2026 02:49:17 +0000

Nearly every "roofing calculator" on the internet is a contractor lead form in disguise. You type in your measurements, hit calculate, and the answer is locked until you hand over your phone number. The math was never the product — your contact info was.

I'm a developer, not a roofer, but I wanted to see what happens if you build the opposite: PitchCalc, five roof-math calculators where the answer shows up in about ten seconds, all computation happens locally in your browser, and there is no backend to store anything.

The actual math is one triangle

Everything in residential roofing reduces to one right triangle: rise over run. The whole engine is a handful of lines:

const ratio = rise / run;

const pitch = `${rise}/12`;                        // X:12 notation (run is usually 12")
const degrees = Math.atan(ratio) * 180 / Math.PI;  // 6/12 → 26.6°
const slopePercent = ratio * 100;                  // 6/12 → 50%
const multiplier = Math.sqrt(1 + ratio * ratio);   // 6/12 → 1.118
const rafterLength = Math.sqrt(run ** 2 + rise ** 2);

From there it's just unit conventions:

Sloped roof area = footprint × multiplier
Roofing squares = area ÷ 100 (a "square" is 100 sq ft, the unit shingles are sold in)
Shingle bundles = ceil(squares × 3 × (1 + waste)) — three bundles per square, typically 10% waste

Five pages, one shared engine: roof pitch, roofing (area/squares/bundles), roof area, rafter, and shingles.

Local-first as a feature, not a limitation

The page says "Measurements stay in this browser" and means it literally: there is no database, no account system, no analytics event carrying your inputs anywhere. Results recompute on every keystroke, so there's no submit button at all.

One detail I like: the input state lives in the URL hash, so a calculation is shareable as a plain link — pitchcalc.com/#rise=6&run=12 opens with a 6/12 pitch preloaded. No encoding endpoint, no shortened URLs, just location.hash.

Trust through visible formulas

Every result panel prints the formula next to the number — √(1 + (rise ÷ run)²) right beside the multiplier value. If you don't trust the output you can check it with a pencil. That's also why the copy button produces something that reads like a takeoff sheet: the audience is a homeowner about to talk to a contractor, or an estimator checking numbers from a truck. The output had to survive being read aloud.

Stack notes

Next.js, fully static — the whole site is pre-rendered pages plus a small client-side engine
No form libraries or state management; controlled inputs and derived values
Print stylesheet treats the result panel as the document, not the page chrome

What I'd add next

Waste factors per roof complexity, valleys/hips geometry, metric units. If you do roof math by hand for something else, tell me in the comments — genuinely collecting the backlog.

Try it: pitchcalc.com — free, no signup, and it will never ask for your phone number.

There's no superscript "q" in Unicode — and other things I learned building a superscript generator

owen — Thu, 27 Aug 2026 09:16:55 +0000

Quick quiz: how do you write "x² + y³" in plain text, no HTML, no LaTeX?

 Easy, right? `²` and `³` are just characters. Now write "E = mcᵠ" — wait, that should be a superscript "q". Try to find it. I'll wait.

 You won't, because **Unicode has no superscript q**. When I built a [free superscript converter](https://literalkit.com/superscript-generator), this turned out to be the tip of

a very weird iceberg. Here's what I learned.

Superscripts aren't formatting — they're separate characters

 Most people assume superscript works like bold: take a character, apply a style. That's how `<sup>` works in HTML, and how rich text editors work.

 Unicode plain text doesn't have styles. Instead, every superscript character is its own pre-composed codepoint, donated to the standard by different communities at different

times:

 - `¹²³` live in **Latin-1 Supplement** (U+00B9, U+00B2, U+00B3) — they've been there since the 1980s.
 - `⁰ ⁴-⁹ ⁺ ⁻ ⁽ ⁾` live in the **Superscripts and Subscripts** block (U+2070–U+209F).
 - Superscript *letters* are scattered across **Phonetic Extensions** (U+1D2C–U+1D7F), because linguists needed them for phonetic transcription: `ᵃ ᵇ ᶜ ᵈ ᵉ ᶠ ᵍ ʰ ...`
 - And a few stragglers like `ˣ` (U+02E3) hide in **Spacing Modifier Letters**.

 So "convert text to superscript" really means "look up each character in a hand-built mapping table someone assembled from four different corners of the standard." There's no

algorithm. It's a scavenger hunt.

The honest-output problem

 Here's where it gets philosophically interesting. The mapping has holes:

 - **No superscript `q`.** It's the famous gap. Proposals exist, but as of today there's no official codepoint.
 - **Uppercase letters are incomplete** — you get `ᴬ ᴮ ᴰ ᴱ ᴳ ᴴ ᴵ ᴶ ᴷ ᴸ ᴹ ᴺ ᴼ ᴾ ᴿ ᵀ ᵁ ⱽ ᵂ`, but try spelling a full sentence in superscript caps and you'll hit walls fast.
 - Subscripts are even sparser: `ₐ ₑ ₕ ᵢ ⱼ ₖ ₗ ₘ ₙ ₒ ₚ ᵣ ₛ ₜ ᵤ ᵥ ₓ` — that's most of what exists.

 Most converters on the web quietly patch the holes with **lookalike characters** — a Greek letter here, a math alphanumeric symbol there. The output *looks* fine until someone

copies it into a screen reader, a search box, or a font that renders the substitute as tofu (□).

 I made a different call: when a character has no real superscript, the tool says so instead of faking it. It feels worse in the demo and better in real life — what you copy is

what you meant.

Styling plain text that survives copy-paste: a Unicode primer (and the tools I use)

owen — Wed, 05 Aug 2026 02:00:34 +0000

The problem: there is no "bold" in a bio

Here's a scenario you've probably hit: you want to emphasize something in an
Instagram bio, a Discord nickname, a Slack message, or a plain-text README —
and there's no formatting toolbar. No bold, no italic, no superscript button.

The reason is simple: these fields store plain text. Formatting isn't
data; it's a rendering layer applied by a rich-text editor. Take the editor
away and the formatting never existed.

The workaround that does travel with the text is Unicode.

Unicode already contains "styled" characters

Unicode isn't just a bigger ASCII. It includes entire blocks of letter
variants — most notably the Mathematical Alphanumeric Symbols block
(U+1D400–U+1D7FF), which encodes bold, italic, script, fraktur, double-struck,
monospace, and more as distinct characters:

x → 𝐱 (bold), 𝑥 (italic), 𝚡 (monospace)
A → 𝔸 (double-struck), 𝔄 (fraktur)
2 → ² (superscript, from a much older block)

Because these are real characters with their own codepoints, they survive
copy-paste into any plain-text field. That's the whole trick behind "font
generator" sites — no fonts are involved, just a codepoint lookup.

The catch: honest vs. fake conversion

There's a subtle quality problem most converters have. Coverage is uneven:
superscript has no lowercase b (Unicode simply never encoded one), italic
has no capital Q, and so on.

Many tools quietly paper over the gaps by borrowing lookalike characters
from unrelated scripts — a Greek letter here, a Cyrillic one there. It looks
fine until screen readers mangle it, search can't find it, or a font renders
it as tofu. A good converter instead:

converts what has a real mapping,
leaves the rest untouched,
and tells you which characters stayed unchanged.

The tools I settled on

I got tired of hand-searching codepoint tables, so I now use
LiteralKit — a free collection of 50+ focused
Unicode tools. Three things make it work for me as a developer:

Everything runs locally in the browser. No accounts, no uploads — your
text never leaves the page. Paste, convert, copy, done in seconds.

Honest output. It never substitutes lookalike characters. Unsupported
characters pass through unchanged, and the page discloses its coverage up
front. For a notation tool, that honesty matters more than a big feature list.

One tool per page, one job per tool. No popups, no multi-step funnels.
A few I keep bookmarked:

Superscript Generator — x², footnote-style notation for plain-text docs and READMEs
Fancy Text Generator — italic/bold/script/monospace Unicode styles for bios and profiles
Case Converter — boring, but I reach for it weekly

The full set (Wingdings and runic translators, symbol pickers, a symbol
identifier, and more) lives in the tool directory.

Takeaway

Styled plain text is just Unicode arithmetic — but doing that arithmetic by
hand is a waste of your time. Know the trick exists, know that coverage has
honest gaps, and let a tool that respects those gaps do the mapping.