The short version

I learn things, I forget things, and then I re-learn the same things six months later. This blog is my attempt to break that cycle. Every post here is a note to future-me, published in public just in case it helps present-you too.

The best way to learn something deeply is to explain it to someone else. The second best way is to write it down where your future self can find it.

What you’ll find here

This isn’t a niche blog with a content strategy and a posting calendar. It’s a personal one, so expect whatever I’m genuinely interested in at the time. In practice, that means:

• Practical tutorials — things I actually built, with working code you can copy.
• Deep dives — topics like closures, CSS layout, or Git internals, explained the way I wish someone had explained them to me.
• Field notes — tools, setups and workflows I’m trying out, with honest verdicts.
• Opinionated rants (occasionally) — I promise to keep these short and well-argued.

What you won’t find here

• AI-generated filler. Every word here was typed by a human (me), fueled by coffee.
• “10x developer” hustle content. I write code, I make mistakes, I fix them. That’s the whole brand.
• Paywalls, popups, or newsletter guilt-trips. There’s an RSS feed and that’s it.

Why a blog and not just tweets or videos?

Nothing against short-form content, but some ideas need more than 280 characters and a thread emoji. A blog post:

1. Is searchable — Google can find it years later. Good luck finding a tweet from 2023.
2. Is permanent — I own this site. No algorithm decides who sees it.
3. Forces clarity — writing 1,000 words about something exposes every gap in my understanding.

That last point is the real reason I’m here. Writing is thinking, and publishing is accountability.

The plan

New posts every couple of weeks. If you want to follow along, grab the RSS feed, star the repo on GitHub, or just bookmark the site like it’s 2009.

And if you’re thinking of starting your own blog: do it. It costs nothing — I built this entire site with Jekyll and GitHub Pages for free, and I wrote a whole tutorial about it.

See you in the next post. ✍

Why Jekyll?

Jekyll is a static site generator: you write posts in Markdown, and it turns them into plain HTML files. For a personal blog, that means:

• Free hosting — GitHub Pages serves static sites for free, straight from your repo.
• Blazing fast — there’s no database or server-side rendering. Just files.
• Version controlled — every post is a commit. Full history, branches, pull requests for your own blog.
• Markdown-native — if you can write a README, you can write a blog post.

Step 1: Create the repository

GitHub gives every user one special repository: <username>.github.io. Push a site there and it goes live at https://<username>.github.io. Create it, then clone it locally:

git clone https://github.com/<username>/<username>.github.io.git
cd <username>.github.io

Step 2: Set up Jekyll

You’ll need Ruby. On most systems:

# macOS (with Homebrew)
brew install ruby

# Ubuntu / Debian
sudo apt install ruby-full build-essential

# Then install Jekyll
gem install jekyll bundler

Create a Gemfile in your repo root so builds are reproducible:

source "https://rubygems.org"

gem "jekyll", "~> 4.3.0"
gem "jekyll-feed", "~> 0.17"      # RSS feed
gem "jekyll-seo-tag", "~> 2.8"    # meta tags
gem "jekyll-sitemap", "~> 1.4"    # sitemap.xml
gem "jekyll-paginate", "~> 1.1"   # homepage pagination
gem "webrick", "~> 1.8"           # `jekyll serve` on Ruby 3+

Step 3: Add the config

Jekyll is configured with a single YAML file, _config.yml:

title: My Awesome Blog
description: Thoughts on code and other things.
url: https://<username>.github.io

permalink: pretty
markdown: kramdown

plugins:
  - jekyll-feed
  - jekyll-seo-tag
  - jekyll-sitemap
  - jekyll-paginate

paginate: 5
paginate_path: /page:num/

Step 4: Write your first post

Posts live in _posts/ and follow a strict naming convention: YEAR-MONTH-DAY-title.md. Each one starts with front matter — a YAML block that Jekyll reads for metadata:

---
layout: post
title: "My First Post"
date: 2026-09-10 09:00:00 +0000
tags: [hello, blogging]
---

Hello, world! This is my first post.

## A section heading

Some text with `inline code` and a [link](https://example.com).

The {{ site.title }} style double-curly syntax you see in Jekyll themes is Liquid, the templating language. Layouts in _layouts/ and reusable snippets in _includes/ let you build pages from components:

{% for post in site.posts limit: 5 %}
  <a href="{{ post.url }}">{{ post.title }}</a>
{% endfor %}

Inside your own posts, wrap any Liquid-looking code in raw tags ({% raw %} … {% endraw %}), otherwise Jekyll will try to render it. Ask me how I know.

Step 5: Preview locally

bundle install
bundle exec jekyll serve

Open http://localhost:4000 and there’s your blog, with live rebuilds on every save.

Step 6: Deploy with GitHub Actions

The modern way to publish is a workflow file at .github/workflows/jekyll.yml that builds your site and deploys it to Pages on every push to main:

name: Deploy Jekyll site to GitHub Pages

on:
  push:
    branches: [main]

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: "3.3"
          bundler-cache: true
      - uses: actions/configure-pages@v5
      - run: bundle exec jekyll build
        env:
          JEKYLL_ENV: production
      - uses: actions/upload-pages-artifact@v3

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@v4

Then go to your repo’s Settings → Pages and set Source to GitHub Actions. Push to main, wait a minute, and your blog is live. Every future post is just git push away.

What I added on top

The basics above get you a working blog in an afternoon. This site adds a few extras, all in the repo if you want to steal ideas:

Final thoughts

Could I have used Next.js, Astro, or Hugo? Sure — they’re all great. But for a personal blog, Jekyll hits a sweet spot: dead simple, free forever, and boring in the best possible way. The less time I spend on infrastructure, the more time I spend writing.

Now stop reading about blogging platforms and go write something. The best blog setup is the one that’s already published.

The one-sentence definition

A closure is a function that remembers the variables from the scope where it was created — even after that scope has finished executing.

That’s it. Everything else is commentary. Let’s prove it:

function makeCounter() {
  let count = 0; // ← this variable "should" disappear when makeCounter returns

  return function () {
    count += 1;
    return count;
  };
}

const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

makeCounter() finished running on line 1 of the usage. But count is still alive, privately held by the returned function. That private, persistent memory is the closure.

Why should you care?

Because closures are everywhere in real code:

1. Private state (without classes)

function createBankAccount(initialBalance) {
  let balance = initialBalance;

  return {
    deposit(amount) { balance += amount; return balance; },
    withdraw(amount) {
      if (amount > balance) throw new Error("Insufficient funds");
      balance -= amount;
      return balance;
    },
    getBalance() { return balance; },
  };
}

const account = createBankAccount(100);
account.deposit(50);      // 150
account.balance;          // undefined — truly private!
account.getBalance();     // 150

No #private syntax, no TypeScript, no classes — just a closure doing what closures do.

2. Function factories

function greetWith(greeting) {
  return function (name) {
    return `${greeting}, ${name}!`;
  };
}

const sayHello = greetWith("Hello");
const sayHi = greetWith("Hi");

sayHello("Ada"); // "Hello, Ada!"
sayHi("Grace");  // "Hi, Grace!"

Each returned function carries its own greeting. This pattern shows up constantly in middleware, event handlers, and configuration.

3. Debouncing (a real-world classic)

function debounce(fn, delay) {
  let timerId; // ← shared across every call of the returned function

  return function (...args) {
    clearTimeout(timerId);
    timerId = setTimeout(() => fn.apply(this, args), delay);
  };
}

const search = debounce((query) => fetchResults(query), 300);
input.addEventListener("input", (e) => search(e.target.value));

The timerId persists between keystrokes because of the closure. Without it, you’d need a global variable or a class — messier either way.

The classic gotcha (and why let fixed it)

You’ve probably seen this interview question:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// logs: 3, 3, 3  😱

All three callbacks close over the same i, which is 3 by the time they run. The old-school fix was an IIFE; the modern fix is let, which creates a fresh binding per iteration:

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// logs: 0, 1, 2  ✅

Each iteration gets its own i, so each closure captures its own value. Mystery solved.

The mental model

When you define a function in JavaScript, it doesn’t just capture code — it captures a backpack containing references to all the variables in scope at that moment. Wherever the function goes (returned, passed as a callback, stored in an object), the backpack goes with it.

function outer() {
  const backpack = "packed 🎒";
  return function inner() {
    console.log(backpack); // inner carries `backpack` wherever it goes
  };
}

const fn = outer();
fn(); // "packed 🎒"

Closures don’t copy values — they hold references to variables. If the variable changes later, the closure sees the new value. This is the source of both their power and 90% of closure bugs.

Quick self-test

What does this log, and why?

function makeAdders() {
  const adders = [];
  for (var i = 1; i <= 3; i++) {
    adders.push(() => i * 10);
  }
  return adders;
}

const [a, b, c] = makeAdders();
console.log(a(), b(), c());

Wrapping up

• A closure = a function + the variables it remembers from where it was defined.
• Use them for private state, function factories, and callbacks that need memory (debounce, event handlers, memoization).
• Remember they capture references, not copies — let vs var in loops is the classic trap.

Once you see closures, you can’t unsee them: React hooks, Express middleware, module patterns — it’s closures all the way down. And now you actually understand them. You’re welcome, future interview-you.

Here are five small Python scripts I genuinely use. No frameworks, no dependencies beyond the standard library (except one). Copy them, tweak them, make them yours.

1. The Downloads folder rescue

Everyone’s Downloads folder is a disaster zone. This script sorts it by file extension in seconds:

from pathlib import Path

DOWNLOADS = Path.home() / "Downloads"

CATEGORIES = {
    "Images": {".jpg", ".jpeg", ".png", ".gif", ".svg", ".webp"},
    "Documents": {".pdf", ".docx", ".txt", ".md", ".xlsx", ".csv"},
    "Videos": {".mp4", ".mkv", ".mov", ".avi"},
    "Audio": {".mp3", ".wav", ".flac"},
    "Archives": {".zip", ".tar", ".gz"},
    "Installers": {".exe", ".msi", ".dmg", ".deb"},
}

def organize():
    moved = 0
    for file in DOWNLOADS.iterdir():
        if not file.is_file():
            continue
        for folder, extensions in CATEGORIES.items():
            if file.suffix.lower() in extensions:
                target = DOWNLOADS / folder / file.name
                target.parent.mkdir(exist_ok=True)
                file.rename(target)
                moved += 1
                break
    print(f"Organized {moved} files. You're welcome.")

if __name__ == "__main__":
    organize()

Run it monthly. Thank me later.

2. Bulk file renamer

Downloaded 200 photos named IMG_20260815_143822.jpg? Rename them all with a pattern:

from pathlib import Path

def bulk_rename(folder: str, pattern: str, dry_run: bool = True):
    """Rename files to pattern-001.ext, pattern-002.ext, ..."""
    files = sorted(Path(folder).glob("*"))
    files = [f for f in files if f.is_file()]

    for i, file in enumerate(files, start=1):
        new_name = f"{pattern}-{i:03d}{file.suffix}"
        if dry_run:
            print(f"{file.name}  →  {new_name}")
        else:
            file.rename(file.parent / new_name)

if __name__ == "__main__":
    # Always dry-run first!
    bulk_rename("./photos", "vacation", dry_run=True)

Always do a dry run before bulk-renaming anything. There is no undo button for rename(). The dry_run flag exists because I learned this the hard way.

3. Log file detective

Need to find every error in a 500MB log file? Don’t open it in an editor — scan it:

import re
from collections import Counter
from pathlib import Path

ERROR_PATTERN = re.compile(r"ERROR|CRITICAL|Traceback", re.IGNORECASE)

def scan_logs(path: str, context_lines: int = 2):
    lines = Path(path).read_text(errors="replace").splitlines()
    error_lines = [i for i, line in enumerate(lines) if ERROR_PATTERN.search(line)]

    print(f"Found {len(error_lines)} error lines in {len(lines):,} total lines\n")

    # Show the most common error messages
    messages = Counter(
        lines[i].strip()[:100] for i in error_lines if "Traceback" not in lines[i]
    )
    print("Top errors:")
    for message, count in messages.most_common(5):
        print(f"  {count:4d}x  {message}")

if __name__ == "__main__":
    scan_logs("app.log")

This turns “the app is broken, good luck” into “here are the 3 errors causing 95% of the failures” in about a second.

4. Website uptime checker

A tiny monitor that pings your sites and tells you which ones are down:

import urllib.request
from datetime import datetime

SITES = [
    "https://mrprecioustech.github.io",
    "https://github.com",
]

def check_sites():
    for site in SITES:
        try:
            with urllib.request.urlopen(site, timeout=10) as response:
                status = response.status
                print(f"✅ {site} — HTTP {status}")
        except Exception as e:
            print(f"❌ {site} — DOWN ({e})")

    print(f"\nChecked at {datetime.now():%Y-%m-%d %H:%M:%S}")

if __name__ == "__main__":
    check_sites()

Pair it with cron (*/15 * * * *) and you’ve got a free uptime monitor. No SaaS subscription required.

5. Markdown blog post scaffolder

Since I write this blog in Markdown, I made a script that creates a new Jekyll post with the front matter pre-filled:

import re
from datetime import date
from pathlib import Path

TEMPLATE = """---
layout: post
title: "{title}"
date: {today} 09:00:00 +0000
description: ""
tags: []
accent: indigo
---

Write something great.
"""

def new_post(title: str):
    slug = re.sub(r"[^a-z0-9]+", "-", title.lower()).strip("-")
    today = date.today().isoformat()
    filename = f"_posts/{today}-{slug}.md"

    Path(filename).write_text(TEMPLATE.format(title=title, today=today))
    print(f"Created {filename}")

if __name__ == "__main__":
    import sys
    new_post(sys.argv[1] if len(sys.argv) > 1 else "Untitled Post")

python new_post.py "My Brilliant Idea"
# Created _posts/2026-08-15-my-brilliant-idea.md

The automation mindset

The scripts aren’t the point — the habit is. Every time you catch yourself thinking “ugh, this again,” that’s automation knocking. Start small:

1. Notice the repetition (the “ugh, this again” moment).
2. Do it manually once more, but pay attention to the exact steps.
3. Script the steps — ugly first drafts are fine.
4. Save it somewhere you’ll find it (a scripts/ folder, a gist, this blog).

The best automation isn’t the cleverest one. It’s the one you actually use.

The core idea

Define every color once as a CSS variable, then redefine the variables under a [data-theme="dark"] selector. Everything else in your CSS references variables, never raw colors:

:root {
  --bg: #ffffff;
  --text: #101828;
  --muted: #5b6474;
  --border: #e4e7ee;
  --accent: #4f46e5;
}

[data-theme="dark"] {
  --bg: #0b0f19;
  --text: #e7ebf3;
  --muted: #9aa4b8;
  --border: #202941;
  --accent: #818cf8;
}

body {
  background: var(--bg);
  color: var(--text);
}

Toggle the data-theme attribute on <html> and the entire site re-themes instantly. That’s 90% of the work.

Don’t hardcode colors — anywhere

The one discipline this requires: every color in your CSS must be a variable. The moment you write color: #333 in some component, you’ve created a spot that won’t theme. A few tips:

• Do an audit pass: search your CSS for # and rgb( outside the token definitions.
• Give semantic names (--text, --muted, --border) not color names (--gray-500).
• Remember the sneaky ones: box-shadow, border-color, SVG fill/stroke, ::selection, and form controls.

/* Bad: invisible in dark mode */
.card { border: 1px solid #e4e7ee; }

/* Good: themes automatically */
.card { border: 1px solid var(--border); }

Respect the system preference

Don’t default everyone to light mode. CSS can detect the OS setting:

/* Optional: default to dark for dark-mode OS users, before JS runs */
@media (prefers-color-scheme: dark) {
  :root:not([data-theme]) {
    --bg: #0b0f19;
    --text: #e7ebf3;
    /* ... same dark tokens ... */
  }
}

But duplicating tokens is ugly. Better: handle it in JavaScript (next section) and use the media query only as a signal, not a styling mechanism.

Kill the flash (FOUC)

Here’s the classic dark-mode bug: the page paints light, then JavaScript loads and flips it to dark. That flash is jarring. The fix is a tiny blocking script in <head> that sets the theme before first paint:

<script>
  (function () {
    try {
      var saved = localStorage.getItem("my-theme");
      var theme = saved || (window.matchMedia(
        "(prefers-color-scheme: dark)").matches ? "dark" : "light");
      document.documentElement.setAttribute("data-theme", theme);
    } catch (e) {
      document.documentElement.setAttribute("data-theme", "light");
    }
  })();
</script>

Yes, it’s render-blocking — that’s the entire point. It’s 10 lines; the cost is negligible and the flash is gone.

The toggle button

With the loader script in place, the toggle itself is trivial:

var KEY = "my-theme";

document.getElementById("theme-toggle").addEventListener("click", function () {
  var current = document.documentElement.getAttribute("data-theme");
  var next = current === "dark" ? "light" : "dark";
  document.documentElement.setAttribute("data-theme", next);
  try {
    localStorage.setItem(KEY, next);
  } catch (e) { /* private browsing mode */ }
});

Priority order, which the loader script implements:

1. Saved preference in localStorage (explicit user choice wins).
2. OS preference via prefers-color-scheme.
3. Light as the fallback.

Show the right icon

Your toggle should show a sun in dark mode and a moon in light mode (i.e., show what you’ll switch to). Pure CSS, no JS needed:

.theme-toggle .icon-moon { display: none; }

[data-theme="dark"] .theme-toggle .icon-sun { display: none; }
[data-theme="dark"] .theme-toggle .icon-moon { display: block; }

Both SVGs live in the button; CSS shows the right one.

Polish: smooth transitions

An instant flip can feel abrupt. A short transition on the main surfaces smooths it out:

body {
  transition: background-color 0.25s ease, color 0.25s ease;
}

Keep it subtle (under 300ms) and only on large surfaces — transitioning every element’s colors can cause lag on big pages. And respect users who prefer reduced motion:

@media (prefers-reduced-motion: reduce) {
  body { transition: none; }
}

Checklist

Before you ship dark mode, verify:

• Every color is a variable (search for # and rgb()
• Blocking loader script in <head> — no flash on reload
• Saved preference beats OS preference beats default
• Toggle icon reflects the target theme
• theme-color meta tags for the mobile browser chrome
• Code blocks, tables, images and shadows all checked in both themes
• Reduced-motion users don’t get the transition

Dark mode done right is invisible: users just feel like the site respects them. Now go theme something.

The daily drivers

Editor: VS Code (with Neovim keybindings)

I’ve done the pure-Neovim era, the Emacs curiosity phase, and the “maybe I should try Zed” weekend. I keep coming back to VS Code with the Vim extension: 90% of Vim’s speed with 0% of the config maintenance.

Non-negotiable extensions: Vim emulation, ESLint, Prettier, GitLens, and an error-lens style inline diagnostics plugin. Everything else is negotiable.

Terminal: whatever’s fast + tmux

The terminal emulator matters less than people think — I use the platform default with a Nerd Font. What matters is tmux: persistent sessions, split panes, and the ability to detach from a long-running job and walk away.

My entire tmux config is maybe 15 lines. The best tool config is the one you can recreate from memory.

Shell: zsh + a short prompt

Oh My Zsh was slowing my shell startup to nearly a second, so I stripped it back to the essentials: syntax highlighting, autosuggestions, and git aliases I actually type. Prompt shows: directory, git branch, dirty state. Nothing else. Fast shells make you feel fast.

CLI apps worth installing

These small tools earn their place every single day:

If you install just one: make it fzf. Pipe anything into it and your terminal becomes searchable.

The supporting cast

• Git + GitHub — obvious, but the skill isn’t knowing git, it’s writing good commit messages and small PRs.
• Docker — for “works on my machine” insurance. If a project has more than two dependencies, it gets a container.
• Python — my automation duct tape. Half the scripts on this blog started as “I’ll just quickly…” (see: 5 Python scripts I actually use).
• Obsidian — notes in plain Markdown files I own. No lock-in, works offline, syncs over git.
• Bitwarden — a password manager isn’t optional anymore. Unique 20-character passwords everywhere, one master password in my head.

What I deliberately don’t use

• A second monitor’s worth of dashboards. If a metric doesn’t change what I do today, I don’t need to see it today.
• AI autocomplete I can’t audit. I use AI assistants for boilerplate and explanations — but every line gets read before it gets committed. Trust, but verify, then verify again.
• Eleven note-taking apps. One notes folder. One todo list. Boring and effective.

The meta-lesson

Tools don’t make you productive — removing friction makes you productive. Every tool on this list survived because it removed more friction than it added.

My advice for building your own toolbox:

1. Start boring. Defaults are fine until they hurt. Only optimize real pain.
2. Learn one tool deeply before collecting ten shallowly. A black belt in your editor beats white belts in five.
3. Revisit yearly. I do this audit every July. Tools (and needs) change — your setup should too.
4. Back up your dotfiles. Future-you, setting up a new machine at midnight before a deadline, says thanks.

What’s in your toolbox? If there’s something life-changing I’m missing, I’d genuinely love to hear about it — find me on GitHub.