SQP Dev

Pushing the Vault to TickTick — Closing the Loop Between Obsidian and Task Management

Thu, 28 May 2026 00:00:00 +0000

The vault knows everything. It has the lesson schedule, the practice sessions, the quiz material. TickTick is where the day actually runs — it sits in the calendar, it sends reminders, it blocks time. For a while those two lived separately, and any reschedule meant updating both by hand.

Today that gap is closed.

The Problem

Obsidian is the source of truth for the learning plan. But TickTick is what I actually look at during the day. When a lesson moved, I’d update the calendar note in Obsidian and then forget to touch TickTick. Or update TickTick and leave the vault behind. Either way, something was always out of sync.

Building an AI-Powered Quiz Into the Learning Loop

Wed, 27 May 2026 00:00:00 +0000

Answering questions in your own words is good for learning. Answering them by clicking a button is better than not answering them at all.

That sounds like a low bar, but it’s actually the insight that shaped the quiz system. At 20:00 after a full day I’m not going to write paragraphs about container networking from memory. But I will click through ten multiple choice questions if the friction is low enough and the questions are good.

Reclaim, Google Calendar, and the Morning Briefing Skill

Tue, 26 May 2026 00:00:00 +0000

The moment that changed the whole system was realising that Claude Code is a terrible calendar manager.

Not because it can’t do it — it can. The Google Calendar MCP integration works, skills can create and update events, everything is technically possible. The problem is cost. Every calendar operation burns tokens. Reschedule five tasks and you’ve spent more on API calls than the Reclaim monthly subscription.

So I made a clean decision: Claude Code never touches the calendar for scheduling. That’s Reclaim’s job.

Structuring the Vault Around a Real Learning Plan

Mon, 25 May 2026 00:00:00 +0000

Once the task manager question was settled, I could focus on what the vault actually needed to contain.

The goal was simple: every Docker and Kubernetes lesson should have a home in the vault before I watch it, a note created during it, and a review scheduled after it. No manual steps, no decisions to make in the moment.

The Learning Plan Structure

The Udemy course has 26 lessons spread across Docker and Kubernetes. I mapped them to a 5-week calendar: two sessions per day this week at 09:30 and 11:00, then one session per day at 06:35 from June onwards when I shift to an earlier schedule.

TickTick, Todoist, Reclaim — Finding the Right Task Manager

Sun, 24 May 2026 00:00:00 +0000

Every learning system needs somewhere tasks live. I went through three tools in fairly quick succession, and each one taught me something useful.

TickTick — The Comfortable Choice

I started with TickTick because I already knew it. Simple interface, good mobile app, doesn’t require an hour of setup to get started. For general life tasks it’s perfectly good.

The problem was the edges. TickTick doesn’t connect naturally to Obsidian. There’s no clean way to link a task in TickTick to a note in Obsidian, and no way to query TickTick tasks from inside the vault. Every time I finished a lesson and wanted to log it, I was switching apps, copying information, doing the same thing twice.

Claude Code as a Vault Brain — First Steps

Sat, 23 May 2026 00:00:00 +0000

The DevOps Learning Command Center dashboard existed. The problem was keeping it alive.

A learning system that requires manual maintenance eventually stops being maintained. I wanted Claude Code — the terminal-based AI agent from Anthropic — to handle the vault upkeep so I could focus on the actual learning.

What Claude Code Does

Claude Code runs in your terminal and has direct access to your filesystem. It reads files, writes files, runs commands. Combined with a CLAUDE.md context file that explains who you are and what the vault is for, it becomes something like a personal assistant that actually knows your project.

Building a DevOps DevOps Learning Command Center in Obsidian

Fri, 22 May 2026 00:00:00 +0000

I’m 56, learning DevOps from scratch, and I have a problem with tools.

Not using them — I love tools. The problem is spending more time building the perfect learning environment than actually learning. It’s a trap I know well and fall into anyway.

This time I decided to be deliberate about it. If I was going to build a system, it would be one that genuinely serves the learning — not just looks good in screenshots.

Agentic AI on Bitfrost — YouTube Playlists on Demand

Wed, 20 May 2026 00:00:00 +0000

And now for something completely different.

Last time it was monitoring — metrics, dashboards, alerts. Serious infrastructure business. This time I wanted to see what happens when you put an AI agent on Bitfrost and give it something genuinely frivolous to do: build YouTube playlists.

The Idea

The workflow is simple. You type one line:

Docker Basics | Docker tutorial for beginners

Left of the pipe is the playlist name. Right is the search topic. Hit enter. A few seconds later a private YouTube playlist exists, populated with real videos, curated by Claude.

Building a Homelab Monitoring Stack from Scratch

Tue, 19 May 2026 00:00:00 +0000

If you run a home server, you probably have a rough idea of whether things are working — you can SSH in, run top, check disk space, maybe peek at some logs. But that’s reactive. You only look when something feels wrong. Proper monitoring means you know before something breaks, or at the very least, you know the moment it does.

This is the story of how I set up a full observability stack on my home server, bitfrost — an Ubuntu 24.04 machine running several Docker-based apps.

Helena & Teodor's Game Lab — A Family Side Project

Sat, 16 May 2026 00:00:00 +0000

Sometimes the best projects start with a simple idea: what if the kids could make their own games?

That’s how Helena & Teodor’s Game Lab came about — a small website where my children, Helena and Teodor, get to have their own collection of browser games. The concept is straightforward: a colourful landing page that showcases each game, and clicking “Play” takes you straight in. No downloads, no installs, just open and play.

SQP Kanban — Containerising a Node.js App with Docker

Thu, 14 May 2026 00:00:00 +0000

I’ve been building a simple kanban board called SQP Kanban — a Node.js/Express app backed by MongoDB. The app itself was functional, but it was running bare on my machine with no containerisation, no CI/CD, and no deployment pipeline. Time to fix that.

The App

SQP Kanban is a drag-and-drop project board with columns (To Do, In Progress, Completed, Omit), task cards with date tracking, and colour-coded projects. The frontend is vanilla HTML/JS, the backend is Express with Mongoose, and data lives in MongoDB.

SQP Kanban — The Deployment Process

Thu, 14 May 2026 00:00:00 +0000

This is the second post about containerising SQP Kanban. Here’s how the actual process went.

Step 1 — Dockerfile

Straightforward. Alpine-based Node image, copy package.json first (so npm install gets cached), then copy the app code. The main lesson was getting the layer order right for efficient rebuilds.

Step 2 — Manual Docker Run

Before Docker Compose, I ran everything manually to understand what each piece does:

docker network create sqp-network
docker run -d --name sqp-mongo --network sqp-network -v sqp-mongo-data:/data/db mongo:8
docker build -t sqp-kanban .
docker run -d --name sqp-kanban --network sqp-network -p 4000:4000 -e MONGO_URI=mongodb://sqp-mongo:27017/sqp-kanban sqp-kanban

Four commands. Each one taught me something — networks, volumes, port mapping, environment variables. Worth doing manually at least once before reaching for Compose.

SQP Kanban — Three Bugs That Broke Deployment

Thu, 14 May 2026 00:00:00 +0000

Deploying SQP Kanban looked simple on paper. In practice, three bugs made it interesting.

Bug 1 — Mongoose Refuses to Save

Symptom: Adding projects and tasks worked in the UI, but nothing persisted after a page refresh. The save status was stuck on “Saving…” forever.

Two problems hiding as one. First, the save status update in saveBoard() was a bare template literal that didn’t actually call anything:

// This does nothing — it's just a floating string expression
`Saved ${new Date().toLocaleTimeString()}`

Second — and this was the real blocker — the Mongoose schemas for subdocuments (projects, tasks, columns) used the default _id type of ObjectId, but the frontend was generating IDs with crypto.randomUUID(), which produces UUIDs like b14a56c5-2628-4138-990c-cb685fdf04ce. MongoDB ObjectIds are 24-character hex strings. Mongoose threw a CastError on every save attempt.

Adding HTTPS with Caddy and DuckDNS

Sun, 10 May 2026 00:00:00 +0000

Adding HTTPS with Caddy and DuckDNS

After deploying the application to EC2, it initially worked only through:

http://EC2-IP

The next step was understanding how HTTPS is normally added.

The Stack

I used:

DuckDNS for a free test domain
Caddy as a reverse proxy
Let’s Encrypt certificates managed automatically by Caddy

Final setup:

https://dsuopd.duckdns.org

Architecture

Internet
   ↓
Caddy
   ↓
localhost:3000
   ↓
Docker app container

The application container itself is no longer publicly exposed directly.

First Real Cloud Deployment

Sun, 10 May 2026 00:00:00 +0000

First Real Cloud Deployment

Today I deployed my first real full-stack application to AWS EC2.

The project is a hospital staff allocation system built with:

React + Vite frontend
Express backend
PostgreSQL database
Docker containers
Docker Compose orchestration

What I Learned

The most important thing was understanding how the different layers connect together.

Final architecture:

Browser
   ↓ HTTPS
DuckDNS
   ↓
Caddy reverse proxy
   ↓
Docker app container
   ↓
PostgreSQL container

Deployment Workflow

The workflow looked like this:

Understanding Docker Volumes and PostgreSQL

Sun, 10 May 2026 00:00:00 +0000

Understanding Docker Volumes and PostgreSQL

One of the most confusing parts of my first deployment was PostgreSQL authentication failing even after changing the password in .env.

The important lesson:

PostgreSQL only uses POSTGRES_PASSWORD the first time the database is created.

What Happened

I originally started the database container with password A.

Docker created a persistent volume:

dsu_pg_data

Later I changed the password in .env to password B.

The application then failed with:

Docker Basics — Building and Deploying to EC2

Fri, 08 May 2026 00:00:00 +0000

Docker packages an application and everything it needs into a container. Same image, identical behaviour on any machine. This post covers building a custom nginx image and deploying it to AWS EC2.

Podman on Fedora

Docker doesn’t run inside a Toolbox container — kernel module restrictions. Podman is Docker-compatible and works natively on Fedora:

echo 'alias docker=podman' >> ~/.bashrc
source ~/.bashrc

Same commands, no workarounds needed from this point.

Building a Custom Image

docker-nginx/
├── Dockerfile
└── index.html

FROM docker.io/library/nginx:latest
COPY index.html /usr/share/nginx/html/
EXPOSE 80

docker build -t my-nginx:v1.0 .
docker run -d -p 8080:80 --name my-nginx my-nginx:v1.0

Open http://localhost:8080 — custom HTML served via nginx inside a container.

Automating Terraform with GitHub Actions

Thu, 07 May 2026 00:00:00 +0000

Manually running terraform apply from a laptop works for learning. In the real world, infrastructure changes go through a pipeline. This is how I set one up.

The Goal

Every Pull Request → run terraform plan automatically
Every merge to main → run terraform apply automatically
AWS credentials stored securely as GitHub Secrets — never in code

Workflow File

name: Terraform CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  terraform:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: exercise-02-variables-outputs

    steps:
      - uses: actions/checkout@v3
      - uses: hashicorp/setup-terraform@v2
      - uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-west-2

      - run: terraform init
      - run: terraform fmt -check
      - run: terraform validate
      - run: terraform plan
        if: github.event_name == 'pull_request'
      - run: terraform apply -auto-approve
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'

Problems I Hit

Workflow not showing in Actions tab — GitHub only reads workflow files from the main branch. The file needs to be merged before it’s recognised.

First Terraform Deployment on AWS

Tue, 05 May 2026 00:00:00 +0000

With the environment set up, I wrote my first real Terraform code — a complete VPC with a public subnet, security group, and an EC2 instance running nginx.

What I Built

VPC (10.0.0.0/16)
Public subnet with Internet Gateway
Security group (SSH + HTTP)
EC2 instance (Ubuntu 24.04)
SSH key pair

File Structure

exercise-02-variables-outputs/
├── main.tf
├── variables.tf
├── locals.tf
├── outputs.tf
├── data.tf
├── key.tf
└── terraform.tfvars

Separating resources into logical files keeps things clean and readable.

Setting Up a DevOps Environment on Fedora 42

Fri, 01 May 2026 00:00:00 +0000

Coming from a VFX and IT background, I decided to transition into DevOps. This is the first post in a series documenting that journey.

Why Fedora?

Fedora aligns well with enterprise DevOps — the same package manager (DNF), SELinux by default, and close ties to RHEL. The quirks you solve on Fedora build exactly the troubleshooting mindset DevOps engineers need.

Toolbox for Isolation

Rather than installing everything directly on the host, I use Toolbox — a container-based environment built on Podman. My DevOps tools live in a container called sandbox, keeping the host clean.