Kaggwe Marvin: Notes - Blog

Why I'm drawn to neobrutalism, and how I toned it down

2026-10-26T00:00:00+00:00

Most websites today look the same. Soft gradients, rounded corners, blurry shadows and buttons that fade in slowly. It looks polished, but it is hard to tell one site from another.

Neobrutalism goes the other way. Flat colours, thick black borders, sharp corners and shadows with no blur. Nothing is hidden, and nothing pretends to be glass. When I rebuilt this site, I chose it on purpose. Here is why.

It shows the structure

Brutalism started in architecture. Brutalist buildings leave the raw concrete showing instead of hiding it behind paint. Neobrutalism does the same for the web: every box has a visible border, so you can see how the page is built.

As a developer I like that. Every element is a box anyway. This style stops hiding it.

It is honest about what you can click

A button here looks like a button. It sits on a hard shadow, and when you press it, it sinks into that shadow like a real key. Hover over it and it turns amber at once, with no slow fade.

That instant change is on purpose. A 300 ms fade feels smooth, but it also makes the page feel slow. A snap feels like a switch. You know right away that the site heard you.

It is cheap to load

Flat colours and solid borders are simple CSS. No background images, no heavy blur effects, no animation library. The whole stylesheet for this site is one small file.

That matters to me. Many people here in Kampala browse on mobile data, and every kilobyte costs money. A style built from borders and flat fills loads fast on a slow connection.

Where I toned it down

Classic neobrutalism is loud: bright yellow, pink and cyan, all on one page. My first version of this site used yellow and cyan, and it felt more like a toy than a portfolio. So I set some rules:

Muted colours. A dark charcoal background, steel-grey cards and one accent: a muted amber. One accent means your eye knows where to look.
Sharp corners only. No rounded corners. The grid stays clean.
Instant states. Hover and press change at once. No transitions.
Big blocks stay calm. Buttons fill with amber on hover. Cards only change their shadow, because flashing a whole card of text amber is tiring to read.
Contrast first. Every text colour has to pass the WCAG contrast check. That is why text on amber is always dark, never white.

What it taught me

Picking a strong style does not mean following it blindly. My first plan had shadows in near-black on a near-black background. They looked fine in a mock-up and vanished on a real screen. I measured the contrast, changed the shadow to a lighter slate, and the boxes came back.

A design system is a set of rules you test, not a set of rules you obey. Neobrutalism gave me a clear starting point. Checking it on real screens made it mine.

The CSS for this site is on GitHub if you want to borrow it.

Why I built Voucher Manager: printing hotspot vouchers on RouterOS 7

2026-10-25T00:00:00+00:00

If you run a Wi-Fi hotspot on a MikroTik router, you sell access with vouchers: small printed cards with a username and password. A customer pays, gets a card, and logs in.

On RouterOS 7 this should be a five-minute job. In practice it is not. That is why I built Voucher Manager, a small Windows app that does the whole job in one click.

What changed in RouterOS 7

In RouterOS 7, MikroTik rebuilt User Manager from scratch. It uses a new database, new menus and new commands, and old setups have to be migrated across (MikroTik docs).

The new web page at /um/ is for customers. They can check their usage and buy a plan. It is not a tool for an operator who wants to print 50 vouchers before the evening rush. For that, you go back to the command line.

The five steps RouterOS 7 makes you do

To get one sheet of printable vouchers, you have to do all of this:

Create the users. One /user-manager user add per user, with a name, password and group. There is also an add-batch-users command that makes random users in bulk, but it does not do the next steps for you.
Give every user a plan. A user is linked to a profile (for example "1 day" or "1 week") with a separate command, once per user:
```
/user-manager user-profile add user=abc123 profile=1-day
```
Generate the vouchers. Run generate-voucher on exactly the users you just made, and name a voucher template that you have already uploaded to the router's Files:
```
/user-manager user generate-voucher numbers=*1,*2,*3 voucher-template=printable_vouchers.html
```
Find the output. The router writes an HTML file to um5files/PRIVATE/GENERATED/vouchers/gen_printable_vouchers.html. To open it in a browser, you first need to set a private web username and password in User Manager's advanced settings. Otherwise you copy it off the router another way, such as FTP.
Print it. Open the HTML file and print it, or save it as a PDF.

None of these steps is hard alone. Together, done by hand for every batch, they are slow and easy to get wrong.

Where it goes wrong

Forgetting a profile. A user with no profile attached has no plan, so the card you hand over may not work as sold.
Generating for the wrong users. generate-voucher needs the internal IDs of the right users. Pick the wrong ones and you print old cards again, or miss new ones.
The file is not ready yet. Right after generate-voucher returns, the HTML file may still be being written. Try to download it too early and you get an error.
Typing plan names by hand. One typo in a profile name and the command fails halfway, leaving some users created and others not.

What Voucher Manager does instead

Voucher Manager talks to the router through its API (port 8728, or 8729 with TLS) and runs every step in order:

Test Connection checks your login before anything runs.
Refresh loads your user groups and profiles straight from the router, so you pick them from a list instead of typing them.
It creates each user, attaches the profile you chose, and keeps the ID the router returns.
It runs generate-voucher on exactly those IDs, using your template.
It downloads the HTML file over FTP, and retries a few times if the file is not ready yet.
It turns the file into a PDF with Microsoft Edge or Chrome, ready to print.

If something fails halfway, it still saves a list of the users it already created next to your PDF. Nothing is left on the router without a record.

You can make up to 500 vouchers per batch, with an optional username prefix so you can tell batches apart.

What I learned

Read the API, not just the menus. The RouterOS API returns the ID of every user you create. Keeping those IDs is what makes "generate vouchers for exactly this batch" reliable.
Plan for slow hardware. Routers are small computers. Waiting and retrying is part of the design, not a bug fix.
Ship it properly. I set up a GitHub Actions pipeline that builds a Windows installer and a portable .exe, with SHA256 checksums, every time I tag a release. People who are not developers can install it like any other app.

Try it

Voucher Manager is free and open source. It needs Windows 10 or 11, and your router needs the API and FTP services turned on, a voucher template in Files, and at least one profile and user group.

If you run a MikroTik hotspot and try it, I would like to hear how it goes.

How I built this site: from Hugo to Zola

2025-06-27T00:00:00+00:00

Update, October 2026: this site no longer runs on Hugo. I rebuilt it with Zola and my own small template. The second half of this post explains why.

Building a personal site had been on my to-do list for ages. Working on the Ordin project finally pushed me to do it, because I needed a place to document my progress and show my work.

Version 1: Hugo and hugo-coder

I wanted a site that was:

Fast: static pages load quickly, even on a slow connection
Simple: little setup and little to maintain
Flexible: easy to change later
Developer-friendly: posts in Markdown, changes tracked in Git

Hugo met all four. Setup on Windows took a few commands:

winget install Hugo.Hugo.Extended
hugo new site resume
cd resume
git init

I picked the hugo-coder theme because it was clean, worked on phones and was still maintained. A GitHub Actions workflow built the site and published it to GitHub Pages on every push, so I could focus on writing instead of servers.

What I learned from version 1

Themes are a package deal. A Hugo theme brings its own layouts, styles, scripts and settings. Changing one small thing often meant learning how all the others fit together.
Simple wins. For a small personal site, I would choose simplicity every time.
Ship early, then improve. The first version was basic, but it was live. That beat waiting for perfect.

Working on Ordin taught me the same lessons: documentation matters, and small steps beat big rewrites.

Version 2: Zola and my own template

A year later the site needed a real update. My CV had changed, I had new projects, and the theme carried a lot of code I did not use. So I rebuilt it:

Zola instead of Hugo. Zola is one small program, and its templates are easy to read.
My own template instead of a theme. Now every line of HTML and CSS is mine and does something.
Content as data. My work history, projects and websites live in simple TOML lists. Updating my resume means editing a list, not HTML.
Live downloads. The Downloads tab reads my latest GitHub releases in the browser, so a new release shows up without rebuilding the site.

The result loads faster, has light and dark modes, prints cleanly, and is easier for me to keep up to date.

What I would tell myself at the start

Look past the screenshot when choosing a theme. Check how much code you are taking on, not just how it looks.
Plan your content first. Decide what pages you need before choosing tools.
Keep old links working. When I moved to Zola, I kept the old post addresses, so links people shared still open the right page.

The source code for this site is on GitHub. Feel free to reach out if you have questions about static sites or web development.

Run Linux on Windows 10 or Tiny10 with MSYS2 and QEMU

2025-06-27T00:00:00+00:00

Updated October 2026: fixed commands that do not work on Windows (-daemonize, -cpu host without acceleration, taskkill flags in MSYS2) and removed an install step for a package that does not exist.

If you run Windows 10, or a stripped-down build like Tiny10, and need a small Linux machine, MSYS2 and QEMU are a good fit. They work where WSL or Hyper-V Manager are missing or switched off, and you control every setting.

Why MSYS2 and QEMU?

Light: works on minimal Windows builds like Tiny10
No WSL or Hyper-V Manager needed: QEMU runs as a normal program
Full control: you choose the memory, CPU, disk and network
Faster with acceleration: if your PC supports the Windows Hypervisor Platform, QEMU can use it

What you need

Windows 10, including Tiny10 and other modified builds
At least 4 GB of RAM (8 GB is better)
At least 20 GB of free disk space
Administrator access, only if you want to turn on acceleration (step 2)

Step 1: Install MSYS2

Download the installer from msys2.org and run it.
Open MSYS2 MINGW64 from the Start menu. Use this terminal for every command in this guide, because QEMU is installed into the MINGW64 environment.
Update everything:

pacman -Syu
# If the terminal closes, open MSYS2 MINGW64 again and run:
pacman -Su

Step 2: Install QEMU (and turn on acceleration if you can)

pacman -S mingw-w64-x86_64-qemu wget

The mingw-w64-x86_64-qemu package already includes qemu-system-x86_64 and qemu-img.

Optional, but much faster: turn on the Windows Hypervisor Platform. Open PowerShell as Administrator and run:

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform

Restart Windows afterwards. Some Tiny10 builds remove this feature. If the command fails, skip it and use the slower tcg mode shown below.

Step 3: Download a Linux ISO

This guide uses Ubuntu Server. Get the current LTS ISO from ubuntu.com/download/server and save it into a folder for your VM:

mkdir -p ~/vms/ubuntu
cd ~/vms/ubuntu
# Move the downloaded ISO here, then rename it to keep the commands short:
mv ubuntu-*-live-server-amd64.iso ubuntu-server.iso

Step 4: Create a virtual disk

qemu-img create -f qcow2 ubuntu.qcow2 20G

The qcow2 format only uses space on your drive as the VM fills it.

Step 5: Install Linux

With acceleration (Windows Hypervisor Platform turned on):

qemu-system-x86_64 \
  -accel whpx \
  -m 2048 -smp 2 \
  -drive file=ubuntu.qcow2,format=qcow2 \
  -cdrom ubuntu-server.iso -boot d \
  -netdev user,id=net0 -device e1000,netdev=net0 \
  -vga std

Without acceleration, replace -accel whpx with -accel tcg -cpu max. It works everywhere, but it is several times slower.

If you see an error about kernel-irqchip, use -accel whpx,kernel-irqchip=off.

In the installer:

Choose your language and keyboard.
Keep the default network settings.
Use the entire (virtual) disk.
Create your user. The first user is added to the sudo group automatically.
Tick Install OpenSSH server when asked. This saves a step later.

Step 6: Start the installed system

After the installer finishes, close QEMU and start again without the ISO. This time, forward port 2222 on Windows to port 22 (SSH) in the VM:

qemu-system-x86_64 \
  -accel whpx \
  -m 2048 -smp 2 \
  -drive file=ubuntu.qcow2,format=qcow2 \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 -device e1000,netdev=net0 \
  -vga std &

The & at the end runs QEMU in the background so you get your terminal back. (QEMU's -daemonize option does not work on Windows.)

If you did not install OpenSSH during setup, log in through the QEMU window and run:

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh

Then connect from Windows:

ssh your_username@localhost -p 2222

Step 7: Make start-up scripts

Batch file (double-click to start)

Save this as C:\msys64\home\%USERNAME%\start-ubuntu.bat:

@echo off
cd /d C:\msys64\home\%USERNAME%\vms\ubuntu
start "Ubuntu VM" C:\msys64\mingw64\bin\qemu-system-x86_64.exe ^
  -accel whpx ^
  -m 2048 -smp 2 ^
  -drive file=ubuntu.qcow2,format=qcow2 ^
  -netdev user,id=net0,hostfwd=tcp::2222-:22 -device e1000,netdev=net0 ^
  -display none
echo Ubuntu VM started. Connect with: ssh your_username@localhost -p 2222

start runs QEMU in its own process, and -display none hides the window, because you will use SSH.

Shell script (from MSYS2 MINGW64)

Save this as ~/vms/start-ubuntu.sh:

#!/bin/bash
cd ~/vms/ubuntu
qemu-system-x86_64 \
  -accel whpx \
  -m 2048 -smp 2 \
  -drive file=ubuntu.qcow2,format=qcow2 \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 -device e1000,netdev=net0 \
  -display none &
echo "Ubuntu VM started. Connect with: ssh your_username@localhost -p 2222"

Make it executable and run it:

chmod +x ~/vms/start-ubuntu.sh
~/vms/start-ubuntu.sh

Managing your VM

Check that it is running:

tasklist | grep -i qemu

Shut it down cleanly (from inside the VM):

sudo shutdown -h now

Force it to stop (only if it hangs). In MSYS2, Windows-style flags need a double slash, because MSYS2 turns /F into a file path:

taskkill //F //IM qemu-system-x86_64.exe

From Command Prompt, the normal taskkill /F /IM qemu-system-x86_64.exe works.

Managing sudo users inside Linux

Check your access:

sudo whoami
# Should print: root

Add another sudo user:

sudo adduser newuser
sudo usermod -aG sudo newuser
groups newuser

Passwordless sudo (optional, and only on a test VM):

sudo visudo
# Add this line at the end:
your_username ALL=(ALL) NOPASSWD:ALL

Troubleshooting

qemu-system-x86_64: command not found You are in the wrong terminal. Open MSYS2 MINGW64, or add it to the path:

export PATH="/mingw64/bin:$PATH"

WHPX: No accelerator found or the VM will not start with -accel whpx The Windows Hypervisor Platform is off or missing (common on Tiny10). Turn it on (step 2), or use -accel tcg -cpu max.

Very slow VM You are probably running without acceleration. Give it fewer jobs: -smp 2, 1 to 2 GB of RAM, and Ubuntu Server without a desktop.

Missing DLL errors on Tiny10 Install the latest Microsoft Visual C++ Redistributable.

SSH says "connection refused" The VM may still be booting. Wait a minute. Check that SSH is running inside the VM with systemctl status ssh.

Security tips

Use a strong password, or better, SSH keys.
Turn on the firewall inside the VM: sudo ufw allow OpenSSH && sudo ufw enable.
Keep it updated: sudo apt update && sudo apt upgrade.
Give sudo only to users who need it.

Wrapping up

You now have a full Linux server on Windows 10 or Tiny10, with no WSL and no Hyper-V Manager. It is great for learning Linux administration, testing software, or running tools that only work on Linux.

Next ideas:

Share a folder between Windows and the VM
Back up ubuntu.qcow2 before big changes (or use qemu-img snapshot)
Try other distributions with the same steps

Connecting a Namecheap domain to Vercel and GitHub Pages

2024-11-30T00:00:00+00:00

Update, October 2026: I did not renew foundug.com, so FoundUG is back on its free address, foundug.vercel.app. I have also added Part 2, about putting my GitHub Pages sites on my new domain, kaggwemarvinvictor.me, and Part 3, about going back to a free address.

A site on something.vercel.app or username.github.io works, but your own domain looks more professional and is easier to remember. I have done this twice, both times with a domain bought on Namecheap:

foundug.com (November 2024) for FoundUG, a Next.js app on Vercel.
kaggwemarvinvictor.me (October 2026) for my sites on GitHub Pages. I got the .me domain free for a year from Namecheap through the GitHub Student Developer Pack.

The idea in one paragraph

A domain is just a name. DNS records tell the internet which server that name points to. You add those records at the place you bought the domain (Namecheap), and you tell the host (Vercel or GitHub) which domain to expect. When both sides agree, the host gives you a free HTTPS certificate.

There are two kinds of records you will use:

A record: points a name to an IP address, like 185.199.108.153.
CNAME record: points a name to another name, like kaggwe-marvin.github.io.

Part 1: Namecheap to Vercel (foundug.com, November 2024)

Step 1: Add the domain in Vercel

Open your project in Vercel.
Go to Settings → Domains.
Type foundug.com and click Add. Choose to add www.foundug.com too, and redirect it to the main domain.

Vercel then shows the DNS records it wants. They show as "Invalid Configuration" until you add them.

Step 2: Add the records in Namecheap

In Namecheap, go to Domain List and click Manage next to the domain.
Open the Advanced DNS tab.
Delete the parking records Namecheap adds by default (a CNAME for www pointing to parkingpage.namecheap.com and a URL Redirect record). If you skip this, they clash with the new records.
Add these two records:

Type	Host	Value
A Record	`@`	`76.76.21.21`
CNAME Record	`www`	`cname.vercel-dns.com.`

@ means the domain itself (foundug.com). Always copy the values from your Vercel dashboard, since Vercel can change them.

Step 3: Wait and check

Go back to Settings → Domains in Vercel. Within a few minutes to an hour, both domains turn green and Vercel adds HTTPS by itself. That is it: every push to GitHub still deploys as before, now on your own domain.

The free foundug.vercel.app address keeps working the whole time. That turned out to matter (see Part 3).

Part 2: Namecheap to GitHub Pages (kaggwemarvinvictor.me, October 2026)

I have two Zola sites on GitHub Pages. I wanted my notes site on the main domain and my resume on a subdomain:

kaggwemarvinvictor.me → the kaggwe-marvin-resume repo
resume.kaggwemarvinvictor.me → the Personal-Resume repo

Step 1: Add the records in Namecheap

In Advanced DNS, delete the parking records, then add:

Type	Host	Value
A Record	`@`	`185.199.108.153`
A Record	`@`	`185.199.109.153`
A Record	`@`	`185.199.110.153`
A Record	`@`	`185.199.111.153`
CNAME Record	`www`	`kaggwe-marvin.github.io.`
CNAME Record	`resume`	`kaggwe-marvin.github.io.`

The four A records are GitHub Pages' addresses. The CNAME records point to your username address, not the repo name. GitHub works out which repo to show from the domain each repo claims.

Step 2: Tell each repo its domain

For each repo, go to Settings → Pages, type the domain under Custom domain and click Save:

kaggwemarvinvictor.me in kaggwe-marvin-resume
resume.kaggwemarvinvictor.me in Personal-Resume

If a site is published from a branch (like gh-pages), this setting is stored in a file called CNAME in that branch. I also keep a static/CNAME file in each Zola site, so the domain survives every rebuild.

Step 3: Update the site's own address

Static site generators build full links from a base address. In Zola that is base_url in config.toml:

base_url = "https://kaggwemarvinvictor.me"

If you forget this, the pages load but the styles and links still point to the old github.io address.

Step 4: Turn on HTTPS

Back in Settings → Pages, wait for the DNS check to pass, then tick Enforce HTTPS. If the box is greyed out, GitHub is still making the certificate. Give it up to an hour.

Old kaggwe-marvin.github.io/... links keep working. GitHub redirects them to the new domain.

Part 3: When a domain expires (foundug.com, 2026)

A domain is rented, not owned. I chose not to renew foundug.com, and once it expired the name stopped working. The app itself was fine, because Vercel still served it at foundug.vercel.app. Moving back took three small steps:

In Vercel, go to Settings → Domains and remove foundug.com and www.foundug.com. Now foundug.vercel.app is the main address again.
In your code, change any place that names the old domain: links, the site URL in your config, and auth or email settings (for example, allowed redirect URLs in Supabase).
Everywhere else, update the link: your CV, GitHub repo description and portfolio.

Lesson: before you buy a domain, decide whether you will pay for it next year too. If not, keep sharing the free address, so links in old CVs and posts never break.

Mistakes I made, so you can skip them

Putting the domain on the wrong repo. I first set the domain on my username.github.io repo, which was empty. On GitHub Pages, a domain on that special repo moves every project site under it. My resume ended up at kaggwemarvinvictor.me/Personal-Resume/. A domain can only belong to one repo, so I had to remove it there before I could add it to the right one.
Leaving the parking records. Namecheap's default records clash with yours. Delete them first.
Changing base_url too early. If you push the new address before the domain is connected, the site loads without its styles. Connect the domain first, then push.

Which one is easier?

Vercel is easier: two records, and it guides you through them. GitHub Pages needs a few more records and one extra setting per repo, but it is free and works well for static sites like mine.

Either way, the pattern is the same: add records at Namecheap, add the domain at the host, wait, then turn on HTTPS. And set a reminder for the renewal date.