Markdown in the repo
This journal is not bolted onto a separate content stack. Posts live beside the application code under priv/posts/, compile at build time with NimblePublisher, and ship with the same release as the LiveView that renders them. That choice is deliberate: editorial history is diffable, reviewable in pull requests, and impossible to “lose” behind a forgotten admin password.
What we gain
- Same pipeline as features — Typos, tone, and factual claims get the same scrutiny as a routing change or a bugfix. If a paragraph contradicts a PRD, someone on the team will see it in review.
- No runtime CMS attack surface — There is no extra login, plugin, or JSON API to harden just to publish a host playbook. Fewer moving parts means fewer surprises at three in the morning.
- Syntax highlighting without client JS — Code samples in posts use Makeup at compile time. Guests and hosts download HTML, not a second bundle of highlighter scripts.
What we do not claim
Blog essays are opinion and education, not policy. Authoritative rules for marketplace behaviour, safety, and compliance live in docs/ and the formal PRDs. When this journal disagrees with a spec, the spec wins until we change it in Git on purpose.
A peek at the wiring
The module that loads these files is intentionally boring—versioned data in, sorted posts out:
use NimblePublisher,
build: HomeDine.Blog.Post,
from: Application.app_dir(:home_dine, "priv/posts/**/*.md"),
as: :posts,
highlighters: [:makeup_elixir, :makeup_erlang]If you are contributing copy, treat filenames and front matter as part of the contract: the slug comes from the path, and the map at the top must stay valid Elixir.
Trade-offs we accept
Editors cannot push a hotfix from a phone without a laptop. We are fine with that for now; the audience for these notes is people planning meals and products, not breaking news. When we need faster iteration, we will still prefer automation (e.g. scheduled deploys) over a second source of truth.
Stay in the loop
We publish host playbooks, guest etiquette, and engineering notes here. Follow the engineering and platform tags when you care how the product is built—not only how it looks in the browser.