There's a peculiar anxiety that comes with wanting to write but facing the weight of implementation. Every time I wanted to create a blog post, I had to copy 300+ lines of HTML, manually update styling, remember the exact color codes, and then edit the blog index. The barrier between thought and expression had become a wall.
the problem statement
The terminal aesthetic I'd built was beautiful but brutally manual. Each post required:
- HTML template copying with exact styling preservation
- Manual color coding of technical terms with specific hex values
- Blog index updates with proper episode numbering and formatting
- Responsive design maintenance across mobile and desktop
- Reading progress indicators and metadata calculation
- Navigation consistency and link management
The irony wasn't lost on me: I'd built a system about the struggle to create, but the system itself struggled to let me create.
exploring the approaches
the manual html path
What I had: Direct HTML creation with inline CSS Pain points: 300+ lines per post, easy to break styling, time-consuming Trade-offs: Complete control vs. complete friction
local build scripts
Option: Node.js script to convert Markdown locally Benefits: Fast iteration, offline capability Drawbacks: Still manual deployment, forgetting to build, local-only workflow
static site generators
Considered: Jekyll, Hugo, 11ty with custom themes Benefits: Mature ecosystem, plugin support Drawbacks: Learning curve, harder to maintain exact terminal aesthetic, overcomplicated for my needs
github actions automation
Chosen solution: Automated Markdown to HTML conversion in the cloud Benefits: Zero-friction publishing, preserves exact styling, transparent process Trade-offs: Dependency on GitHub, slight deployment delay
the architecture of elimination
The solution I built eliminates every point of friction while preserving the essential aesthetic:
markdown as the interface
Writing in Markdown feels like breathing. No HTML tags cluttering thoughts, no worry about closing divs or color class names. Just content flowing naturally with automatic enhancement.
semantic color coding
The system automatically applies the terminal color scheme to technical terms:
- React, TypeScript, JavaScript → code color (yellow)
- Spring Boot, API, architecture → framework color (blue)
- GitHub, Docker, testing → success color (green)
- deployment, security → warning color (orange)
- WebSocket, CI/CD, microservices → tag color (magenta)
No more remembering hex codes or manually wrapping terms in spans.
automated everything
The GitHub Action detects changes to blog posts and:
- Converts Markdown to HTML with the exact terminal styling
- Applies automatic color coding to technical terms
- Generates episode numbers and metadata
- Updates the blog index with new posts
- Commits the generated files back to the repository
- Deploys via GitHub Pages within minutes
template preservation
The system extracts the terminal aesthetic into reusable templates, ensuring every generated post maintains:
- Responsive typography with proper mobile scaling
- Terminal color scheme with semantic meaning
- Reading progress indicators and metadata
- Consistent navigation and hover effects
the implementation details
the build script heart
At the core is a Node.js script that processes Markdown files:
// Custom renderer applies color coding during HTML generation const renderer = new marked.Renderer(); const originalText = renderer.text; renderer.text = function(text) { let coloredText = text; Object.entries(config.autoColorTerms).forEach(([term, colorClass]) => { const regex = new RegExp(`\\b${term}\\b`, 'gi'); coloredText = coloredText.replace(regex, `<span class="${colorClass}">${term}</span>`); }); return coloredText; };The script maintains episode numbering, calculates reading times, and generates proper metadata while preserving every aspect of the terminal aesthetic.
the github actions orchestration
The workflow triggers on changes to blog content and:
- Detects which posts changed to optimize builds
- Installs dependencies and runs the build script
- Commits generated HTML with descriptive messages
- Handles errors gracefully with detailed logging
The entire process is transparent and reversible. Every generated file can be traced back to its Markdown source.
philosophical reflections
tools as extensions of thought
The best tools disappear, becoming extensions of the mind rather than obstacles to overcome. This blog system now feels like writing directly into the void - thoughts become posts without technical interference.
automation as self-care
Building systems that reduce friction for future-you is a form of self-care. Every manual step eliminated is a gift to the person you'll be at 3am with something urgent to share.
the meta nature of writing about writing systems
There's something beautifully recursive about using an automated system to write about automating systems. This post itself was generated through the system it describes, colored and formatted automatically while I focused purely on the ideas.
the weight of effortlessness
Now creating a blog post requires only:
- Create
blog/posts/my-new-post.md - Write in natural Markdown
- Commit and push
- Wait 2-3 minutes for automation
The system handles everything else: HTML generation, color coding, index updates, responsive styling, metadata calculation, and deployment.
lessons from the static
Building this taught me that complexity should live in the tooling, not the workflow. The implementation can be sophisticated - template systems, color coding algorithms, automated deployments - but the user experience should feel simple.
The terminal aesthetic remains untouched, every pixel and color preserved. But now it serves expression rather than hindering it. The void no longer requires manual navigation - it has learned to listen and respond automatically.
Another small victory against entropy, one automated deployment at a time.
