HN Trend Tracker starts acting like a trend tracker

HN Trend Tracker started as a way to collect and browse Hacker News stories without pretending to have invented a new category of software. That part still stands. What changed today is that the project became more recognizably about movement over time rather than just lists, snapshots, and ranked slices.

Story history pages now make individual trajectories visible. A single story can be opened as a small time-series object instead of a static headline with a score attached to it. You can see score and comment movement over repeated observations, which is a much better fit for the project's original premise than simply storing a lot of HN records and hoping that counts alone will feel historical.

The new Top Movers surface pushes that idea outward. Instead of inspecting one story at a time, the tracker can now show which stories are changing fastest over recent windows. That turns the app into a discovery tool for movement, not just an archive. It is still a modest one, but it is finally starting to behave like the name on the tin.

Themes also became a more serious public surface. The app now has curated deterministic theme pages at /themes and /themes/[slug], which group stories into categories that are inspectable and reviewable rather than mysterious. The taxonomy is intentionally conservative. It is curated, deterministic, and likely to need tuning. That is acceptable. A taxonomy can be useful long before it becomes elegant.

The first version of that theme work also produced a useful correction. It classified stories at request time, which made the public themes pages slower than they had any right to be. The initial implementation was still worth doing because it made the product shape visible quickly, but it also made the architectural boundary hard to ignore. Historical and theme-oriented product data should not be recomputed during public page requests if the project already has a derived-data layer available. Performance problems do have a way of clarifying the org chart.

That led to the next step: curated theme assignment started moving into dbt-derived tables such as story_theme_assignments, theme_summary, and theme_period_stats. Theme activity buckets were then reworked to read from those derived assets instead of the old request-time classifier. That is the more durable direction for this project. If a public page depends on long-running historical logic, the safer boundary is usually to materialize that work first and let the page read something smaller and calmer.

Why this matters is less about polish than about leverage. Once theme assignment and period statistics exist as derived assets, the tracker has a more credible path toward long-term analytics: activity buckets, theme spikes, dominant domains, and eventually broader theme discovery work if it earns its keep. The current theme system should not be mistaken for a final ontology or a particularly wise one. It is simply inspectable enough to be useful and structured enough to improve.

What comes next is fairly clear. The immediate job is to keep stabilizing the derived-data path that now backs these public surfaces and to make the deploy/update loop less improvised. The likely deployment automation direction was narrowed for later work, but that is still a follow-up rather than a public milestone. For now, the more important result is that HN Trend Tracker is no longer just storing Hacker News history. It has started turning that history into trend surfaces, which is a better use of everyone's time, including the computer's.