Starting a dev log
This is the first entry in the Imperfect Systems dev log. The plan is simple: write down what I’m building, what breaks, and what I’d do differently, in public.
Why a dev log
Most of the interesting work happens between releases. A dev log captures that middle part: the dead ends, the small wins, the decisions that only make sense once you’ve seen the alternative fail.
How this blog works
The blog isn’t bespoke. The components, the related-posts scoring, the content schema, and the syntax-highlighting config all come from a shared package, @vdaluz/astro-blog, which also powers another site. This page is mostly glue: a content collection, two route files, and a neon-on-black theme.
import { blogSchema } from '@vdaluz/astro-blog';
const blog = defineCollection({
loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
schema: blogSchema({ defaultAuthor: 'Imperfect Systems' }),
});
The components are driven entirely by CSS-variable design tokens, so the same code renders in this site’s neon-green theme and in a completely different palette elsewhere. No forks, no copy-paste.
What’s next
More posts, and probably more sites sharing the same package. For now: it builds, it’s green, and it works.
Related reading
A CI failure playbook for a one-person Rails project
Writing down the rules for what to do when CI goes red on a solo Rails project, and the GitHub limitation that turned the merge gate into a load-bearing comment.
Building blog-manager, part 1: the Blog model and a UI that doesn't look like a scaffold
Starting blog-manager: a Rails Blog model with Active Record Encryption for per-blog credentials, and a CRUD UI I'd actually enjoy using.