Blog¶

Build a Second Brain with Claude Code and Obsidian

Most note-taking apps are graveyards. You clip an article, it sits in a folder, you never read it again. The knowledge doesn't connect to anything. It doesn't compound. After three years you have 4,000 notes and can't find anything.

This guide builds something different: a self-maintaining knowledge base where Claude Code acts as your librarian. You dump raw material in. Claude reads it, writes structured wiki articles, cross-links related concepts, and files everything. You ask questions. The answers become new notes. The library grows smarter every time you use it.

The architecture is based on Andrej Karpathy's LLM Wiki pattern: a persistent, compounding knowledge base where an LLM does the bookkeeping you'd never do yourself.

Git Workflow for Release Management: Branches vs Tags

Most teams invent their Git strategy as they go. One developer starts tagging releases. Another uses branches. A third creates a hotfix branch and never deletes it. By the time you need to patch a six-month-old release, nobody remembers what release-final-v2 means or where hotfixes actually landed.

A clear branching strategy prevents this. This post covers a battle-tested Git workflow built around two parallel approaches — version control with branches and version control with tags — and tells you exactly when to use each.

Agent-Driven Software Factory: Replace Vibe Coding With a 12-Agent Pipeline

Vibe coding is not a software development process.

Fire a prompt, accept the result, ship it. Fast in the same way skipping tests is fast — until something breaks and you can't explain why. The output is plausible-looking code with no validated problem, no verified requirements, no threat model, no acceptance tests, no deployment strategy. One feature. Eleven things that were supposed to happen but didn't.

The Software Factory Agent replaces that with a 12-agent pipeline. One developer runs the chain. Specialized agents handle market research, product scoping, UX design, security, implementation, testing, validation, and deployment — each in its own clean context window with only the tools it needs.

Two modes. Discovery mode (12 agents) validates the market, defines the product, and designs the UX before any engineering starts. Feature mode (9 agents) skips straight to implementation for incremental work on an existing product.

CKA Mock Exam — Complete Questions & Solutions

Exam Rules Reminder

• Use sudo to edit files in /etc/kubernetes/manifests/
• Use sudo for kubelet restart and system-level debugging
• Use documentation links provided in each question
• SSH into the correct node as specified in the question
• Always verify the correct namespace before applying changes

The Karpathy Skill: Four Rules That Make You a Better AI-Era Engineer

Most developers use AI coding assistants wrong.

They fire off a vague prompt, accept the first 200-line response, and then spend the next hour debugging why the "helpful" code broke three other things. The tool is fast — the outcome is slow.

Andrej Karpathy — the Stanford AI researcher who co-founded OpenAI, led Tesla's Autopilot team, and built NanoGPT from scratch — distilled decades of engineering intuition into four rules that are now circulating as a CLAUDE.md template for AI coding assistants. These rules are not about AI. They are about how senior engineers think — and they happen to be exactly what you need to get great results from any AI coding tool in 2026.

This post unpacks every rule with the why, concrete examples, and practical habits you can start using today.

PostgreSQL High Availability with Patroni: 2026 Edition

Running a single PostgreSQL instance in production is a liability. When it goes down — and it will — so does your application. High availability is not optional for production databases; it is the baseline.

This guide builds a production-grade PostgreSQL HA cluster using the fully open-source community stack: PostgreSQL 17 from PGDG, Patroni 4.x, etcd 3.5, pgbackrest 2.58, and HAProxy. No vendor-specific packages. No proprietary repositories. Everything here runs on Rocky Linux 9 or AlmaLinux 9 and stays fully open-source.

PostgreSQL Performance Tuning for Application Developers (2026 Edition)

Slow queries are not a database problem. They are a design problem.

A query that takes 4 seconds on a table with 100 million rows almost always has a fixable root cause: missing index, wrong index type, table bloat, exhausted connection pool, or configuration defaults that were set for a 1GB dataset and never updated. Most performance problems are found — and solved — at the query and schema level before any hardware needs to be touched.

PostgreSQL Server Tuning: The Complete 2026 Configuration Guide

A freshly installed PostgreSQL server is configured to run safely on a shared laptop from 2005. shared_buffers = 128MB. work_mem = 4MB. max_connections = 100. These defaults have not changed in over a decade — and they are deliberately conservative so the server starts without crashing on anything.

Your production server is not a 2005 laptop.

This guide covers every postgresql.conf parameter that matters, the OS-level settings that underpin them, and a ready-to-use configuration reference for common server sizes — all updated for PostgreSQL 17 on Linux in 2026. It is the server configuration companion to the query and index tuning guide, which covers EXPLAIN, indexes, and PgBouncer.

CKA Cheat Sheet 2026

Exam Domains: Storage 10% | Troubleshooting 30% | Workloads & Scheduling 15% | Cluster Architecture 25% | Services & Networking 20%

Kubernetes version on exam: 1.34+ — kubectl is pre-configured, sudo required for node-level tasks. Allowed docs: kubernetes.io/docs, kubernetes.io/blog, helm.sh/docs

Quick Wins — Always Do First

# Set alias (saves time on every command)
alias k=kubectl
export do="--dry-run=client -o yaml"   # k run pod1 --image=nginx $do > pod.yaml
export now="--force --grace-period=0"  # k delete pod pod1 $now

# Autocomplete
source <(kubectl completion bash)
complete -o default -F __start_kubectl k

# Context switching (exam has multiple clusters)
kubectl config get-contexts
kubectl config use-context <context-name>
kubectl config current-context

Prompt Engineering: The Anthropic Playbook

There is no magic phrase that makes an LLM smarter. There is no secret syntax, no special keyword, no hidden trick that unlocks better results.

What there is: a systematic discipline for giving models what they actually need to do good work. That discipline has a name — prompt engineering — and Anthropic's Harrison Chase and Christiaan Ryan spent an entire workshop teaching it the right way, using a real production example, and showing exactly where simple intuitions fail.

Source: Harrison Chase & Christiaan Ryan, Anthropic — "Prompting 101" (YouTube)