日本百名山 — shared checklist

A multi-person checklist for the 100 Famous Mountains of Japan (Fukada Kyūya, 1964). Next.js + Postgres, deployed on Vercel. One page, readable by anyone; edits need the admin password.

The mountain data was extracted from hyakumeizan-checklist.pdf: kanji, furigana, English name, prefecture, region, elevation, best season, and notes.

Artwork

The header print is Katsushika Hokusai, from Thirty-six Views of Mount Fuji (c. 1830). Both are public domain and were taken from Wikimedia Commons:

• public/red-fuji.jpg — Fine Wind, Clear Morning (凱風快晴), shown in light mode. Source
• public/black-fuji.jpg — Shower Below the Summit (山下白雨), shown in dark mode. Source

They are a matched pair — the same mountain in fair weather and in storm — so dark mode changes the weather rather than the theme. Both are resized to 1200px wide and recompressed; replace them at that width to keep the header crop.

Setup

1. Database (Neon)

In the Vercel dashboard: Storage → Create Database → Neon, attach it to this project. Vercel injects DATABASE_URL automatically. Copy the same pooled connection string into .env.local for local work.

cp env.example .env.local   # then fill in DATABASE_URL
npm install
npm run db:setup            # creates tables, loads the 100 mountains

db:setup is idempotent — re-run it any time.

2. Password

Set SITE_PASSWORD in .env.local and in Vercel's environment variables.

Anyone can read the checklist. To change it — tick a peak, set a date, add or rename or delete a person — go to /login and enter that password. The page is not linked from anywhere; type the URL. A visitor sees every edit control still in place but inert, explaining itself on hover. Buttons and form fields are dimmed; the seals in the table and on the peak cards are not, because they are the data the page exists to show. Either way the server rejects the write, so what a visitor sees is an explanation rather than the lock.

Leaving SITE_PASSWORD unset means npm run dev counts every request as the admin. That is the local default: clone, npm run db:setup, npm run dev, edit.

A production build reads the same missing variable the opposite way — nobody is admin, and the checklist is readable but frozen. The convenience is worth having locally; deployed, a dropped variable would otherwise hand edit rights to the internet while looking exactly as intended.

There are no accounts, and the password is stored as plain text in the environment rather than hashed — it guards one person's checklist from passing strangers, and a hash would only help against someone who can already read the deployment's environment.

3. Run

npm run dev      # http://localhost:3000
npm run build    # what Vercel runs

Deploying

Push to GitHub, import the repo in Vercel, and set the two environment variables (DATABASE_URL comes from the Neon integration, SITE_PASSWORD you choose). Run npm run db:setup once against the production database.

Data model

mountains   one row per peak; fukada_number is nullable so non-hyakumeizan
            peaks can share the table
people      one row per person; each becomes a column on the page.
            is_public decides whether anyone who is not logged in sees them
ascents     (person_id, mountain_id) -> climbed + optional date_climbed

A missing ascents row means "not climbed", so adding a mountain or a person is a single INSERT with no backfill.

Who is shown publicly

Reads are public — anyone with the URL sees the checklist — so each person has a Public switch in their column header, visible only once you are logged in. Unticked, that person is hidden from visitors completely: no column, no banner seal, no entry in the map filter, and none of their ascents are sent to the browser at all. The switch is enforced in app/page.tsx's queries, not in the page's markup, which is what makes "hidden" mean hidden rather than invisible.

is_public defaults to true, so a person added by the form is public until you untick them.

update people set is_public = false where name = 'Kriti';   -- or use the switch

Adding people

Use the form at the bottom of the page, or:

insert into people (name, sort_order) values ('Kriti', 3);
update people set name = 'Kriti' where name = 'A';   -- rename a placeholder

Adding mountains

insert into mountains (name_kanji, name_kana, name_en, prefecture, prefecture_ja,
                       prefecture_sort, region, elevation_m, best_season, notes,
                       latitude, longitude)
values ('槍ヶ岳', 'やりがたけ', 'Mt. Yari', 'Nagano', '長野県',
        18, 'N. Alps', 3180, 'Jul–Sep', 'chains', 36.3419, 137.6475);

fukada_number left null sorts the peak to the end of its prefecture group. prefecture_sort is the geographic north-to-south rank; a new prefecture with no value defaults to 999 and lands at the bottom.

Coordinates and the map

latitude / longitude are populated for all 100 peaks but are approximate — recorded from general knowledge, not a surveyed source, and good to roughly a kilometre. Fine for map pins; not for navigation. See db/coordinates.json for per-peak provenance.

The 地図 tab draws them as triangles on an outline of Japan, inked in proportion to how many of the selected people have climbed each peak. Because the coordinates are approximate, the map stops zooming at roughly one prefecture — far enough in to separate neighbouring peaks, not so far that the error becomes visible.

This is the beginning of the README. Read the rest at the original. Read the full README ↗