Posts on hxmn.dev

Getting Started with Hugo for Technical Blogging

Thu, 16 Apr 2026 10:00:00 +0300

Hugo is one of the fastest static site generators available, and it is particularly well-suited for technical blogs. In this post, we will walk through why Hugo stands out and how to get a blog running from zero.

Why Hugo?

There are plenty of static site generators to choose from — Jekyll, Eleventy, Astro, Next.js — but Hugo has a few properties that make it compelling for engineering blogs:

Speed. Hugo builds are measured in milliseconds, not seconds. A site with hundreds of posts still builds in under a second.
Single binary. No Node.js, no Ruby, no Python runtime. Install one binary and you are done.
Batteries included. Taxonomies, RSS, sitemaps, syntax highlighting, and image processing are all built in.

Installation

On macOS with Homebrew:

brew install hugo

Verify the installation:

hugo version

Creating a Site

hugo new site my-blog
cd my-blog

Adding a Theme

Hugo has a rich theme ecosystem. For a clean, professional look, PaperMod is an excellent choice:

git submodule add https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod

Then set theme = 'PaperMod' in your hugo.toml.

Writing Your First Post

hugo new content posts/my-first-post/index.md

This creates a new post using the archetype template, pre-filled with frontmatter fields for date, tags, categories, and more.

What’s Next

Once you have the basics running, there is a lot more to explore — custom shortcodes, deployment pipelines, and content organization strategies. Check out the post on Docker Compose for local development for an example of how we structure technical content on this blog.

Effective Code Reviews: A Practical Guide

Tue, 14 Apr 2026 09:00:00 +0300

Code review is one of the highest-leverage activities in software engineering. Done well, it catches bugs, spreads knowledge, and raises the bar for the whole team. Done poorly, it becomes a bottleneck that breeds resentment.

Here is what we have learned about making reviews work.

Review the Right Things

Not every comment needs to be about correctness. The most valuable review feedback falls into a few categories:

Bugs and logic errors — the obvious one.
Design concerns — will this approach scale? Is there a simpler way?
Readability — can someone unfamiliar with this code understand it in six months?
Missing edge cases — what happens when the input is empty, nil, or enormous?

Avoid bikeshedding on style issues that a linter should handle. If you find yourself arguing about bracket placement, add a linter rule and move on.

Keep Reviews Small

Large pull requests get rubber-stamped. Small, focused PRs get thoughtful reviews. Aim for under 400 lines of meaningful changes per PR.

If a change is inherently large — say, a database migration with model updates and API changes — break it into a stack of dependent PRs.

Provide Context

As an author, make the reviewer’s job easier:

Write a clear PR description explaining why, not just what.
Link to the relevant issue or design document.
Call out areas where you are uncertain and want extra scrutiny.

Be Kind, Be Direct

Use “we” language: “We should add a nil check here” instead of “You forgot a nil check.” Suggest, don’t demand. And when code is good, say so — positive feedback is underrated.

Automate What You Can

Linters, formatters, type checkers, and CI pipelines should catch the mechanical stuff before a human ever sees the PR. This frees reviewers to focus on design and logic.

For more on setting up local development environments that support this workflow, see Docker Compose for Local Development.

Docker Compose for Local Development

Sun, 12 Apr 2026 14:00:00 +0300

Getting a new team member productive on day one is a good litmus test for your development setup. If it takes more than a git clone and a single command to get the app running locally, there is room for improvement. Docker Compose makes this achievable.

The Basic Setup

A minimal compose.yaml for a web app with a database:

services:
 app:
 build: .
 ports:
 - "8080:8080"
 volumes:
 - .:/app
 depends_on:
 - db
 environment:
 DATABASE_URL: postgres://dev:dev@db:5432/myapp

 db:
 image: postgres:16
 ports:
 - "5432:5432"
 environment:
 POSTGRES_USER: dev
 POSTGRES_PASSWORD: dev
 POSTGRES_DB: myapp
 volumes:
 - pgdata:/var/lib/postgresql/data

volumes:
 pgdata:

Start everything with:

docker compose up

Adding Services

Most real applications need more than just an app server and a database. Here is how to add Redis for caching:

 redis:
 image: redis:7-alpine
 ports:
 - "6379:6379"

And a worker process:

 worker:
 build: .
 command: ./run-worker
 depends_on:
 - db
 - redis
 environment:
 DATABASE_URL: postgres://dev:dev@db:5432/myapp
 REDIS_URL: redis://redis:6379

Practical Tips

Use volumes for data persistence. Named volumes (like pgdata above) survive docker compose down. Use docker compose down -v only when you intentionally want a clean slate.

Use health checks. Instead of relying on depends_on alone (which only waits for the container to start, not for the service to be ready), add health checks:

 db:
 image: postgres:16
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U dev"]
 interval: 5s
 timeout: 5s
 retries: 5

Keep .env out of version control. Use .env.example as a template and add .env to .gitignore.

Use profiles for optional services. Not everyone needs the monitoring stack running all the time:

 grafana:
 image: grafana/grafana
 profiles: [monitoring]
 ports:
 - "3000:3000"

Start it only when needed: docker compose --profile monitoring up.

What This Enables

A reproducible local environment means:

New team members are productive in minutes, not days.
“Works on my machine” stops being an excuse.
Code reviews can focus on logic instead of environment issues.

That last point matters more than it seems. When reviewers can docker compose up and test a PR locally, the quality of feedback goes up dramatically.