Forem: szokker

I’m Trying to Pay My Car Insurance With an Automated Website

szokker — Sun, 01 Mar 2026 21:24:58 +0000

A few months ago I had a simple idea.

What if I could build a small technical website that runs mostly on automation… and eventually makes just enough money to cover one monthly expense?

Not rent.
Not financial freedom.
Just my car insurance.

€67 per month.

That’s it.

The Build Phase

I started building TutorialsHub as a multilingual technical tutorial site (English, Dutch, French).

At first it was messy:

Triple-language routing bugs
Content formatting breaking refresh
YAML indentation issues
Search not working
Language switch not updating content

Every fix felt like progress.

I automated content generation with Python.
Fixed the formatting pipeline.
Structured the folders properly.
Cleaned up the deployment.

It slowly stopped feeling like a “project” and started feeling like a system.

The Real Goal

Not “passive income guru lifestyle”.

Just this:

If the site can generate €67/month from ads,
it pays for my car insurance.

Which means:

My website pays for a real-world expense.

Code turns into something tangible.

The project becomes an asset.

At an estimated €10 RPM, I need around 6,000–7,000 monthly pageviews.

That’s not crazy.
That’s achievable.

Where It Is Now

1. - Multilingual structure works
2. - Automated publishing works
3. - SEO slowly kicking in
4. - Some pages already ranking

Now I’m in the polish + distribution phase:
Fix UX.
Improve search.
Engage in communities.
Write better tutorials.

I’ll update this post when the insurance is officially paid by traffic.

€67/month.

That’s the milestone.

If you’re curious about the journey, want to see how I’m structuring the automation, or just want to follow the experiment — feel free to check it out and give honest feedback.

And I’m genuinely curious:

What’s the smallest “real-world expense” you’d like your side project to cover?

Coffee?
Gym membership?
Hosting costs?
Something bigger?

Let’s see how many of us are quietly trying to make our code pay for something tangible.

Why I Built My Own To-Do App (Even Though There Are Thousands Already)

szokker — Thu, 26 Feb 2026 09:34:19 +0000

A few months ago I realized something slightly ridiculous. I had more than five different to-do systems and still felt disorganized. I had one app on my phone, another one in the browser, something inside a project management tool, and even a physical notebook that I kept going back to because somehow it felt more reliable than all the digital options combined. Every time I thought “this is the one,” a few weeks later I was switching again.

The problem wasn’t that these apps were bad. Most of them were polished, feature-rich, and designed by teams of people who clearly understood productivity psychology better than I ever will. They had reminders, syncing, priorities, tags, smart suggestions, statistics, streaks — everything. But none of them actually felt right.

At some point I realized that I was constantly adapting myself to the app instead of the app adapting to how I think. I was reorganizing tasks because the structure demanded it, not because it made sense to me. I was clicking around features I didn’t even need. It started to feel like I was managing the tool more than managing my work.

One evening, instead of reorganizing my tasks for the tenth time, I opened my editor and thought: what if I just build the simplest possible to-do app for myself? Not something revolutionary. Not something to compete with the big players. Just something that works exactly the way my brain works.

No feature overload. No gamification. No “you’ve completed 73% of your weekly productivity goals.” Just tasks. Simple, clear, structured in a way that makes sense to me.

That’s how I ended up building my own to-do app with React.

It wasn’t about proving anything. It wasn’t about launching the next startup idea. It was more like reclaiming control. When you build your own tool, every decision has a reason. If something feels unnecessary, you remove it. If something feels missing, you add it. There’s no friction between you and the system because you are the one designing it.

The interesting part is that building it actually helped me more than using it. It forced me to think about how I prioritize tasks, how I break down bigger ideas, how I move things from “I should do this” to “this is done.” It became less about having a to-do list and more about understanding how I structure my work.

And there’s something satisfying about using something you built yourself. Even if it’s simple. Especially if it’s simple. It doesn’t feel like just another app. It feels like your own system.

I documented the whole process of building it, the structure, the thinking behind it, and how it evolved. If you’re curious, you can see the full progress here:

The Day Docker Refused to Start My Website (And Why It Was My Fault)

szokker — Sun, 22 Feb 2026 14:16:43 +0000

A few weeks ago, everything was running perfectly.
My tutorial site was fully automated.
Every morning:
Content generated
Astro built the static files
Docker restarted NGINX
The new version went live
It felt clean. Controlled. Professional.
Then one restart killed the entire site.
No warning.
No partial failure.
Just… dead.
The Error
Docker wouldn’t start the NGINX container.
The only message:

Bind mount failed: '/volume1/docker/tutorialshub/dist' does not exist

That was it.
No stack trace.
No helpful explanation.
Just refusal.
And the site was offline.
My First Thought: “Docker is Broken.”
I checked:
docker-compose.yml
NGINX config
Port mappings
Permissions
Everything looked correct.
The volume mapping was simple:

./dist:/usr/share/nginx/html

This had been working for weeks.
So what changed?
The Missing Folder
I SSH’d into my Synology NAS and navigated to:

/volume1/docker/tutorialshub/

There was no dist folder.
And suddenly everything made sense.
Astro generates /dist during build.
No build → no folder.
No folder → Docker refuses to mount it.
Docker wasn’t broken.
It was protecting me.
The Real Problem: Deployment Order
Here’s what happened:
I triggered a container restart
The build step hadn’t completed
/dist didn’t exist
Docker tried to mount it
Docker aborted startup
Static sites look simple.
But they depend entirely on build artifacts.
If your artifact doesn’t exist,
your “application” doesn’t exist.
Why Docker Refuses Missing Paths
I learned something important that day.
Docker bind mounts are strict by design.
If you use a bind mount:

./dist:/usr/share/nginx/html

Docker assumes:
“You, the operator, guarantee that this path exists.”
If it doesn’t, Docker fails immediately.
It doesn’t auto-create.
It doesn’t guess.
It doesn’t forgive.
And honestly — that’s good.
Because silent failures are worse.
The Fix (And the Embarrassment)
The solution was painfully simple.
Run the build first.

npm run build docker-compose down docker-compose up -d

That’s it.
But the lesson wasn’t about the command.
It was about architecture.
Static Sites Shift Complexity
We love static sites because:
No backend
No runtime logic
No database
Fast performance
But static doesn’t remove complexity.
It shifts it.
From runtime → to deployment time.
Your build artifact becomes your application.
If you mishandle that artifact,
everything breaks instantly.
The SEO Side Effect
While the container was failing:
Pages returned 404
Sitemap became inaccessible
Google Search Console stalled indexing
Infrastructure stability isn’t just DevOps vanity.
It directly affects SEO trust.
That was an unexpected lesson.
What I Changed After
I stopped relying on manual sequencing.
Instead of:
Build → Restart → Hope
I added validation.
Now my deploy script:
Builds
Verifies /dist exists
Only then restarts containers
I’m also experimenting with a multi-stage Docker build
to remove bind mounts completely.
Because the cleanest solution is:
No filesystem dependency at all.
What This Taught Me
Self-hosting teaches you fast.
Docker isn’t “magic.”
Static sites aren’t “simple.”
Automation hides fragility.
But failures like this are valuable.
Because they expose architectural weaknesses.
And once you see them,
you can design better systems.
If you're containerizing static frameworks like Astro,
double-check your build artifacts before restarting anything.
That one missing folder cost me an afternoon —
and temporarily killed my site.
Lesson learned.
If there’s interest, I can write a deeper technical breakdown of the deployment architecture and the improvements I’m implementing next.
The full technical write-up is here:

How I Built an Advanced SQL Tutorial — and Self-Hosted It on My Own NAS

szokker — Fri, 20 Feb 2026 11:01:12 +0000

A few days ago I ran into a small frustration.

There are tons of beginner SQL tutorials online…
But when it comes to real-world, advanced queries used for data analysis, things get vague fast.

So I decided to write one myself.

Not on Medium.
Not just here on Dev.to.

But on a static site I built and host entirely from my own NAS.

🧠 The Goal

I wanted to create a tutorial that covers:

Multi-table JOIN strategies

Window functions

Conditional aggregations with CASE

Common Table Expressions (CTEs)

Practical data-analysis style queries

Something useful for people who already know SQL basics — and want to level up.

Here is the tutorial

🛠 Why I Self-Hosted It

Instead of publishing only on big platforms, I built my own stack:

Astro (static site generator)

Docker

Nginx

Nginx Proxy Manager

Everything running on my Synology NAS

Why?

Because I wanted:

Full control

No dependency on external CI services

Automated rebuilds

Zero-downtime static deployment

A playground to learn real infrastructure

It turned into a fun DevOps + content hybrid project.

📊 Unexpected Bonus

After publishing, I started seeing:

Google Search Console impressions

Reddit traffic

Organic indexing beginning

Which is pretty motivating when you're running everything from your own hardware.

🔥 What You’ll Actually Learn In The Tutorial

This isn’t theory-heavy.

It walks through:

Complex analytical queries

Real aggregation patterns

SQL techniques used in reporting and dashboards

Clean examples you can run on any relational database

If you're into SQL for analytics, this might be useful.

Here it is again:

💬 Feedback Welcome

I’m continuously improving both the content and the infrastructure behind it.

If you’re into:

SQL

Self-hosting

Docker

Static site automation

Or just building things from scratch

I’d love to hear your thoughts.

What advanced topic should I cover next?

I Automated My Synology NAS to Generate and Deploy Tutorials Daily

szokker — Thu, 19 Feb 2026 10:26:01 +0000

A few weeks ago I started building a small tutorial website.

At first, everything was manual:

Write content

Add markdown

Run build

Restart container

It worked… but it was boring.

So I automated the entire pipeline on my Synology NAS.

Now every morning:

A Python script generates new content

The content is validated

Astro rebuilds the site inside Docker

Nginx restarts

The updated site goes live automatically

All without me touching anything.

🏗 My Stack

Synology NAS

Docker + Docker Compose

Astro (static site)

Python automation scripts

Scheduled tasks (cron-like)

🔄 The Automation Flow

Here’s the simplified flow:

Scheduled task runs every morning

Python script generates tutorials

Script validates output

Docker Compose runs Astro build

Nginx container restarts

New content is live

The rebuild takes ~1 minute.

The old version of the site keeps running until the container restarts, so there’s no downtime.

🧠 Why I Built It

Two reasons:

I wanted to learn more about automation in a real environment.

I wanted a self-maintaining content system.

It’s basically a mini CI/CD pipeline running on a NAS.

⚙️ The Rebuild Script

For those interested, this is the rebuild part:

#!/bin/bash cd /volume1/docker/tutorialshub || exit 1 /usr/local/bin/docker compose run --rm astro-builder /usr/local/bin/docker restart astro-nginx

Simple, but effective.

📈 What I Learned

Self-hosting forces you to understand your stack.

Automation saves mental energy.

Small systems compound over time.

Build in public works — I shared the setup on Reddit and it sparked interesting discussions.

I’m continuing to iterate on this system.

If there’s interest, I can write a deeper technical breakdown of the content generation + validation layer.

The project is live at tutorialshub.be if anyone’s curious.

7 ES6 Features Every JavaScript Developer Should Know

szokker — Wed, 18 Feb 2026 10:33:04 +0000

ES6 completely changed how we write JavaScript.

If you’re still using var everywhere… this is for you.

Here are 7 essential ES6 features you should master.

1️⃣ let & const

let name = "John"; const pi = 3.14;

Block-scoped and safer than var.

2️⃣ Arrow Functions

const add = (a, b) => a + b;

Shorter syntax + lexical this.

3️⃣ Template Literals

const greeting =Hello ${name};

Clean string interpolation.

4️⃣ Destructuring

const { name, age } = person;

Cleaner object handling.

5️⃣ Default Parameters

function multiply(a, b = 1) {}

6️⃣ Spread / Rest

const newArray = [...oldArray];

7️⃣ Classes

class Dog extends Animal {}

🎯 Why ES6 Matters

Cleaner code

Less boilerplate

Modern patterns

Industry standard

👉 Full detailed explanation with examples here

Getting Started With Docker: Run Your First Container in 5 Minutes

szokker — Wed, 18 Feb 2026 10:27:05 +0000

If you’ve heard about Docker but never actually used it, this is your starting point.

Let’s run your first container in under 5 minutes.

No fluff.

🐳 What Is Docker?

Docker lets you package applications into containers so they run the same everywhere.

No more:

“It works on my machine.”

🛠 Step 1: Install Docker

Download Docker Desktop from docker.com.

After installation, check:

docker --version

If you see a version number → you’re good.

🚀 Step 2: Run Your First Container

Pull and run the hello-world image:

docker pull hello-world docker run hello-world

If you see a success message → Docker works.
📦 Useful Beginner Commands

docker ps docker ps -a docker stop <container_id> docker rm <container_id>

These let you manage containers.

🧠 Why This Matters

Once you understand this:

You can run databases locally

Test apps in isolation

Deploy projects consistently

Build real DevOps skills

👉 I wrote the full beginner walkthrough here

CSS Flexbox for Beginners: Build Responsive Layouts the Easy Way

szokker — Wed, 18 Feb 2026 10:23:41 +0000

f you're just starting with CSS layouts, Flexbox might look confusing at first.

But once it clicks… it REALLY clicks.

In this guide, I’ll walk you step-by-step through building a simple responsive layout using Flexbox — without overcomplicating things.

🚀 Why Use Flexbox?

Flexbox makes it easy to:

Center elements (finally!)

Distribute space evenly

Build responsive layouts

Align items vertically and horizontally

And you don’t need complicated positioning hacks.

<div class="flex-container"> <div class="flex-item">Item 1</div> <div class="flex-item">Item 2</div> <div class="flex-item">Item 3</div> </div>

Simple container + children. That’s it.

.flex-container { display: flex; justify-content: center; align-items: center; height: 100vh; }

Each item now grows equally.

@media (max-width: 600px) { .flex-container { flex-direction: column; } }

On smaller screens → items stack vertically.

That’s the magic.

💡 Common Mistakes

Forgetting display: flex

Confusing justify-content and align-items

Not using flex: 1 when needed

🔥 Final Thoughts

Flexbox removes 80% of layout headaches.

If you're learning CSS, mastering Flexbox is non-negotiable.

👉 I wrote a more detailed version with troubleshooting examples here