i went to my first hackathon last week. wraithathon, mobile track, roughly a day and a night. we came second.

i had been putting this off for years. every time one came up i found a reason: not ready, don't have a team, don't have an idea good enough. the actual reason was simpler than all of that. i had never done one and didn't want to be bad at it in a room full of people.

turns out nobody is watching you. everyone is staring at their own screen, panicking about their own thing.

what we built

sefer. you write one sentence — İstanbul'dan Kapadokya'ya 2 kişi, 3 günlük sakin ve bütçe dostu bir gezi planla — and it gives you a day-by-day route with real transport prices, real hotels, a map, and links to actually book it.

android, kotlin, compose. i took the app, ertuğrul took the scraper: a small fastapi service pulling live prices off the sites that actually sell tickets. two repos, one demo.

the part i'm still happy about is where we let the model do things and where we didn't. gemini parses your sentence and shapes the days. it is not allowed to produce a single price. every number on screen comes from the data layer, and the line under the route title tells you which layer it came from — live scraper, bundled scrape, or an estimate.

that last bit is what actually saved the demo.

the thing that saved the demo

the venue wifi was the venue wifi.

we had built a fallback chain mostly because it felt like the correct thing to do: try the live service, fall back to the last real scrape bundled into the apk, fall back to a distance-based estimate. never show an empty screen, and always say out loud which source you're on.

on stage the live service was not reachable. the app just quietly dropped a layer and kept going. nobody in the room could tell, and if they had asked, the answer was printed right there on the screen.

if there's one thing i took from this: the demo is the product. not the architecture, not the test suite. the three minutes in front of the jury is the whole thing you built, and every decision should be judged by whether it survives those three minutes with no network.

the night

46 commits in about nineteen hours. i can watch the whole night in git log.

the early messages are full sentences. by 3am they read f, easter, map arrows, earth kaldirildi tamamen. somewhere in there the entire ui got rebuilt around the map because we realised navigating between screens was destroying and rebuilding the map twice on the way to a plan. that was not a planned refactor. that was 8pm, someone saying "this feels bad", and doing it anyway.

i also lost real time to turkish lowercase. "İstanbul".lowercase() doesn't do what you want with the default locale, and it silently stopped matching our own data. very funny at noon. not funny at 4am.

what i'd do differently

• sleep some. i didn't. the code i wrote between 4 and 6am was mostly undone by 8. the hours were real, the progress wasn't.
• write the demo script early. we wrote ours near the end and then discovered which paths were fragile. doing it first would have told us what to build.
• decide who owns what in the first hour. we got this one right by accident. two people, two repos, one contract between them, almost no merge pain all night.
• stop polishing. i pushed a launcher icon fix at 5am. nobody looked at the launcher icon.

going again

the honest summary: it was a day of building with no room to overthink, which is the condition i'm best in and almost never actually put myself in. the deadline does something no self-imposed plan has ever done for me.

second place is nice. the thing i'll keep is that i now know what a day of this feels like, and the next one won't have that "i've never done one" tax on it.

going to the next one.

• sefer — the app
• sefer-scraper — the price service

-- moli

turned 18 today.

i kept expecting to feel different. some switch flipping at midnight. it didn't. same room, same projects open, same half-finished repos staring back at me. i woke up and the little age counter on the homepage just rolled over.

writing it down anyway, because the small stuff adds up even when no single day feels like much.

started taking this seriously a few years back. picked up linux properly somewhere in here. broke things, fixed them, broke them again. most of what i know now i didn't a couple years ago — i only really notice it looking back.

so the honest version: i don't have it figured out, and i'm not supposed to yet. the plan is the same as yesterday. keep building small things. ship more than i polish. stay curious.

eighteen just means i get to keep doing that with fewer excuses.

-- moli

most editors are either powerful but messy, or polished but slow.

zed is the first one in a while that feels fast, modern, and opinionated without becoming annoying. after using it seriously, i get the hype.

speed is the feature

people talk about speed like it is a benchmark problem. it is not. it is a mood problem.

when an editor opens instantly, search feels instant, no ui animations at all, no lag, your brain stays in the code instead of noticing the tool.

that is zed's biggest win.

it is written in rust, pushes rendering hard, and actually feels like a native app instead of a web app pretending to be one. vscode is still good, but next to zed it can feel a little heavier and a little older.

not broken. just older.

the defaults are unusually sane

this matters more than plugin people admit.

most editors ask you to assemble your ideal environment from parts:

• install extensions
• fix keymaps
• wire up language servers
• debug your debugger
• repeat on every machine

zed starts from a much better place.

language support is good out of the box. the ui is clean. the keyboard shortcuts make sense. the settings format is readable. even vim mode is good enough that it does not feel like a compromise feature bolted on later.

that last part matters. bad vim mode is worse than no vim mode.

collaboration is not an afterthought

this is where zed still feels weirdly underrated.

most editors treat collaboration like a plugin, a screen share, or a temporary hack. zed treats it like part of the editor itself. shared projects, channels, notes, following another person's cursor, and built-in screen sharing all make more sense than the usual "jump on a call and say line 184" workflow.

if you pair program often, mentor people, or review work live, zed is operating in a category most editors barely acknowledge.

it feels closer to "google docs for code, but serious" than to traditional remote pair tools.

the ai integration is less embarrassing than usual

most ai editor features feel stapled on.

zed's recent direction is more interesting because it is not pretending there will only be one agent forever. the built-in agent exists, but zed also opened up external agents through acp, so the editor can act more like a good client than a locked platform.

that is the right idea.

i do not want my editor to marry one model vendor. i want a good interface for code review, codebase context, multi-file edits, and letting me swap the brain behind it when the market changes again next month.

in 2026, that flexibility matters a lot more than a flashy demo.

it is finally becoming a complete editor

the old criticism of zed was always the same: "cool, fast, but not ready."

that criticism made sense for a while.

it makes less sense now.

the debugger is here. external agents are here. collaboration is mature enough to be a real differentiator. the project is open source. releases ship constantly. it still has rough edges, but it no longer feels like a beautiful preview of a future editor. it feels like an actual editor.

that is a big difference.

where it is still weaker

it is not magic.

if your workflow depends on some ultra-specific vscode extension, zed may still not replace it. if you have built your entire brain around terminal-first neovim workflows, zed can still feel a little too gui-native in places. and because it is moving fast, you should expect some churn.

but these are normal tradeoffs, not fatal flaws.

the important part is that zed is now good enough that people are choosing it for what it is, not just for what it might become.

verdict

zed is good in the way good tools usually are: it removes friction you had quietly accepted.

faster startup. better defaults. real collaboration. a serious vim mode. ai features that are flexible instead of captive. and now enough core editor surface area that recommending it no longer feels like telling someone to "wait for 1.0."

it is not perfect.

it is just one of the few editors right now that actually feels like it was built in the current decade.

that alone makes it worth taking seriously.

-- moli

i have been running linux as my only operating system for over three years now. no dual boot, no macos laptop on the side, no windows vm "just in case." here is everything i learned, broke, fixed, and settled on.

choosing a distro

this is where everyone gets stuck. i have distro-hopped enough to have opinions.

what i have tried

why cachyos

cachyos ships with performance-optimized kernels (bore scheduler, cachyline patches), a graphical installer that actually works, and pacman with parallel downloads out of the box. it is arch underneath so you get the aur and the wiki without the weekend-long install ritual.

# check your scheduler
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# performance

# kernel version
uname -r
# 6.19.7-1-cachyos

if you want arch but value your weekends, cachyos is the answer.

desktop environment

the wayland situation

wayland in 2026 is finally stable enough to recommend to everyone. xwayland handles legacy apps, screen sharing works in browsers, and most compositors have caught up.

i use hyprland. it is a tiling wayland compositor with smooth animations and a config file that actually makes sense.

# ~/.config/hypr/hyprland.conf

monitor=DP-1, 2560x1440@165, 0x0, 1
monitor=HDMI-A-1, 1920x1080@60, 2560x0, 1

input {
    kb_layout = tr
    follow_mouse = 1
    sensitivity = -0.3
}

general {
    gaps_in = 4
    gaps_out = 8
    border_size = 2
    col.active_border = rgb(cba6f7)
    col.inactive_border = rgb(313244)
    layout = dwindle
}

animations {
    enabled = true
    bezier = snappy, 0.05, 0.9, 0.1, 1.05
    animation = windows, 1, 5, snappy
    animation = fade, 1, 4, default
    animation = workspaces, 1, 4, snappy, slide
}

why tiling

once you go tiling, floating feels like chaos. every window has its place. no overlapping, no searching for that terminal you minimized twenty minutes ago.

my layout is usually:

┌──────────────┬──────────┐
│              │ terminal │
│   browser    ├──────────┤
│              │  editor  │
└──────────────┴──────────┘

super + 1-9 switches workspaces. super + enter opens a terminal. super + q closes a window. muscle memory takes a week to build, then you never look back.

status bar

waybar with a minimal config. clock, workspaces, volume, battery, network. no system tray icons because i do not need fifteen applets telling me things i already know.

{
    "layer": "top",
    "position": "top",
    "height": 32,
    "modules-left": ["hyprland/workspaces"],
    "modules-center": ["clock"],
    "modules-right": ["pulseaudio", "network", "battery"],
    "clock": {
        "format": "{:%H:%M}",
        "format-alt": "{:%Y-%m-%d}"
    }
}

the daily workflow

app launcher

rofi on wayland (rofi-wayland fork). fast, themeable, handles both app launching and window switching.

# bind in hyprland.conf
bind = SUPER, d, exec, rofi -show drun -theme catppuccin-mocha

notifications

dunst replaced with mako. lighter, wayland-native, and the config is three lines:

[urgency=low]
background-color=#1e1e2e
text-color=#cdd6f4
border-color=#313244

[urgency=normal]
background-color=#1e1e2e
text-color=#cdd6f4
border-color=#cba6f7

[urgency=critical]
background-color=#1e1e2e
text-color=#f38ba8
border-color=#f38ba8

file management

thunar for when i need a gui, but honestly lf (terminal file manager) handles 90% of my file operations. it is like ranger but written in go and much faster.

# ~/.config/lf/lfrc
set previewer ctpv
set cleaner ctpvclear
set shell zsh
set icons true

screenshots

grimblast. one keybind for area selection, one for full screen, auto-copies to clipboard.

bind = , Print, exec, grimblast --notify copy area
bind = SHIFT, Print, exec, grimblast --notify copy screen

audio and media

pipewire

pipewire replaced pulseaudio and it just works. low latency, bluetooth codec switching, no configuration needed for 99% of use cases.

# check pipewire is running
systemctl --user status pipewire wireplumber

bluetooth

bluetooth on linux used to be a nightmare. with bluez 5.x and pipewire, my sony headphones connect on boot, codec switches to ldac automatically, and battery level shows in waybar.

the only trick: make sure experimental = true is in /etc/bluetooth/main.conf for battery reporting.

music

ncmpcpp + mpd for local music, spotify via the flatpak client. last.fm scrobbling works through mpdscribble for local and the spotify client handles its own.

gaming

the steam deck effect

valve single-handedly made linux gaming viable. proton translates directx to vulkan, and the compatibility database is enormous.

# check vulkan support
vulkaninfo --summary

# install steam
sudo pacman -S steam

what works

• native games: most indie games ship linux builds. factorio, celeste, hollow knight all run natively.
• proton: elden ring, cyberpunk 2077, baldur's gate 3 — all run through proton with minimal setup.
• anti-cheat: the biggest remaining pain point. some games with kernel-level anti-cheat still refuse to run.

what does not

• valorant. vanguard anti-cheat requires windows kernel access. not happening.
• some competitive fps games with aggressive anti-cheat.
• adobe creative suite. not a game, but worth mentioning. gimp and inkscape are good, but they are not photoshop.

performance

on my rx 7900 xtx with mesa drivers, most games run at 95-100% of windows performance. some vulkan-native games actually run faster on linux.

# useful environment variables for gaming
MANGOHUD=1          # fps overlay
DXVK_HUD=fps       # directx translation overlay
mesa_glthread=true  # opengl threading

gamescope

valve's micro-compositor for gaming. handles resolution scaling, hdr, frame limiting. i use it for every game:

gamescope -w 2560 -h 1440 -r 165 -f -- %command%

the pain points

fractional scaling

4k monitors at 150% scaling still have blurry xwayland apps. the fix is per-app: force wayland on electron apps with --ozone-platform=wayland, use native wayland firefox, and accept that some gtk3 apps will look slightly off.

# force electron apps to use wayland
echo "--ozone-platform-hint=auto" >> ~/.config/electron-flags.conf

printer setup

every six months i need to print something and every six months i rediscover that cups exists. the web interface at localhost:631 is ugly but functional.

video calls

screen sharing in teams/zoom on wayland requires xdg-desktop-portal-hyprland. once installed, it works. but "once installed" took me an hour of searching the first time.

sudo pacman -S xdg-desktop-portal-hyprland

firmware updates

fwupd handles most firmware updates through fwupdmgr. but some hardware (looking at you, certain wifi cards) still requires windows to update firmware.

dotfiles management

i use chezmoi for syncing configs across machines. wrote a whole post about it, but the tldr:

chezmoi init --apply https://github.com/lostf1sh/dotfiles

one command, entire setup replicated. new machine goes from fresh install to fully configured in under ten minutes.

the ecosystem in 2026

what got better

• wayland: finally mature. screen sharing, clipboard, multi-monitor all work.
• gaming: proton is a miracle. most steam games just work.
• flatpak: sandboxed apps that update themselves. great for gui apps.
• fonts: font rendering on linux is actually better than windows now.

what still needs work

• adobe alternatives: gimp 3.0 is better but the ux gap is still real.
• office compatibility: libreoffice handles most things, but complex excel macros break.
• anti-cheat: kernel-level anti-cheat is the last major gaming barrier.

who should try it

if you are a developer, linux is the obvious choice. your deployment target is probably linux anyway. docker runs natively. package managers are first-class.

if you are a gamer who plays mostly single-player or steam games, you will be fine. check protondb before buying.

if you depend on adobe or microsoft office daily, dual boot or use a vm. do not try to force it.

my current stack

three years in and i do not miss windows. not even a little.

-- moli

everyone knows add, commit, push, pull. but git has an entire layer of powerful tools that most developers never touch. these are the ones that changed how i work.

interactive rebase

this is the single most useful advanced git feature. it lets you rewrite history before pushing.

git rebase -i HEAD~5

this opens your editor with the last 5 commits:

pick a1b2c3d fix login bug
pick e4f5g6h add user avatar
pick i7j8k9l wip
pick m0n1o2p fix typo
pick q3r4s5t add avatar tests

what you can do

real workflow

that wip and fix typo commit? squash them into the commits they belong to:

pick a1b2c3d fix login bug
pick e4f5g6h add user avatar
fixup i7j8k9l wip
fixup m0n1o2p fix typo
pick q3r4s5t add avatar tests

result: clean history with three meaningful commits instead of five noisy ones.

the golden rule

never rebase commits that have been pushed to a shared branch. rewriting published history breaks everyone's local repos. rebase your local branch before pushing, not after.

git bisect

you know something broke between version 2.1 and now, but there are 200 commits in between. bisect finds the exact commit using binary search.

git bisect start
git bisect bad                 # current commit is broken
git bisect good v2.1           # this tag was working

git checks out the middle commit. you test it and tell git:

git bisect good   # this commit is fine
# or
git bisect bad    # this commit is broken

git narrows down by half each time. 200 commits takes at most 8 steps.

automated bisect

even better — give it a test script:

git bisect start HEAD v2.1
git bisect run npm test

git runs npm test at each step and finds the first failing commit automatically. walk away, get coffee, come back to the answer.

when i use it

• a test that used to pass now fails and nobody knows why
• performance degraded somewhere in the last month
• a css layout broke and the commit is not obvious from the diff

bisect turns a needle-in-a-haystack problem into a five-minute task.

git worktrees

worktrees let you have multiple branches checked out at the same time in different directories. no stashing, no context switching, no losing your place.

# create a worktree for a hotfix
git worktree add ../hotfix-branch hotfix/login-crash

# now you have two directories:
# ~/project          → main branch (your current work)
# ~/hotfix-branch    → hotfix/login-crash

why this is better than stashing

with stash:

1. save your work (git stash)
2. switch branch (git checkout hotfix)
3. fix the issue
4. switch back (git checkout main)
5. restore your work (git stash pop)
6. hope nothing conflicts

with worktrees:

1. create worktree (git worktree add)
2. fix the issue in the other directory
3. done. your original work never moved.

managing worktrees

git worktree list           # see all worktrees
git worktree remove ../hotfix-branch  # clean up when done
git worktree prune          # remove stale entries

i keep a convention: worktrees go in sibling directories named after the branch. ~/project stays on main, ~/project-feat-x is a feature branch.

when i use them

• reviewing someone's pr while i have uncommitted work
• working on a hotfix without disrupting my feature branch
• running tests on one branch while coding on another

git hooks

hooks are scripts that run automatically at specific points in the git workflow. they live in .git/hooks/ or you can manage them with tools like husky or lefthook.

useful hooks

# .git/hooks/pre-commit
#!/bin/sh
# run linter before every commit
npm run lint --quiet
if [ $? -ne 0 ]; then
    echo "lint failed. fix errors before committing."
    exit 1
fi

# .git/hooks/commit-msg
#!/bin/sh
# enforce conventional commit messages
if ! head -1 "$1" | grep -qE "^(feat|fix|docs|style|refactor|test|chore)(\(.+\))?: .{1,50}"; then
    echo "invalid commit message format."
    echo "use: type(scope): description"
    exit 1
fi

shared hooks with lefthook

# lefthook.yml
pre-commit:
  parallel: true
  commands:
    lint:
      run: npx eslint {staged_files} --fix
    format:
      run: npx prettier {staged_files} --write
    types:
      run: npx tsc --noEmit

pre-push:
  commands:
    test:
      run: npm test

hooks catch problems before they reach the remote. lint on commit, test on push, format on save. automate the boring stuff.

the escape hatch

git commit --no-verify  # skip hooks (use sparingly)

sometimes you need to commit broken code to switch context. that is fine. just do not push it.

git reflog

reflog is git's undo button. it records every change to HEAD, even things that git log does not show.

git reflog

a1b2c3d HEAD@{0}: commit: add tests
e4f5g6h HEAD@{1}: rebase: squash
i7j8k9l HEAD@{2}: rebase: start
m0n1o2p HEAD@{3}: commit: wip
q3r4s5t HEAD@{4}: checkout: moving from main to feature

recovering from disasters

accidentally deleted a branch:

git reflog                    # find the commit hash
git branch recovered a1b2c3d  # recreate the branch

rebase went wrong:

git reflog                        # find the state before rebase
git reset --hard HEAD@{3}         # go back to that state

force pushed and lost commits:

git reflog                        # they are still there locally
git cherry-pick a1b2c3d           # rescue specific commits

how long does reflog keep things

by default, 90 days for reachable refs and 30 days for unreachable ones. you can change this:

git config gc.reflogExpire "180 days"

the lesson: almost nothing in git is truly lost. if you committed it, reflog remembers.

git stash (properly)

most people know git stash and git stash pop. but stash has more to offer.

named stashes

git stash push -m "wip: login redesign"
git stash push -m "experiment: new api format"
git stash list
# stash@{0}: On main: experiment: new api format
# stash@{1}: On main: wip: login redesign

without names, stash list is a wall of unhelpful "WIP on main" entries.

partial stashes

stash only specific files:

git stash push -m "just the css" -- src/styles/

or interactively choose hunks:

git stash push -p

stash as a branch

if a stash grows complex enough to keep, turn it into a branch:

git stash branch new-feature stash@{0}

this creates a new branch from the stash point and applies the stash. clean.

git blame and log archaeology

blame with context

git blame -L 50,70 src/auth.js

shows who wrote lines 50-70 and when. useful for understanding why code looks the way it does.

ignore formatting commits

if someone ran prettier across the whole codebase, blame becomes useless. fix it:

# create .git-blame-ignore-revs
echo "a1b2c3d  # prettier reformatting" >> .git-blame-ignore-revs
git config blame.ignoreRevsFile .git-blame-ignore-revs

now git blame skips that commit and shows the actual author.

log tricks

# search commit messages
git log --grep="login" --oneline

# find when a function was added
git log -S "function authenticate" --oneline

# find when a function was changed
git log -G "authenticate.*token" --oneline

# show commits that touched a specific file
git log --follow -- src/auth.js

# pretty graph
git log --oneline --graph --all

the -S flag (pickaxe) is incredibly powerful. it finds the commit that added or removed a specific string. combine it with -p to see the actual diff.

git cherry-pick

take a specific commit from one branch and apply it to another.

git checkout main
git cherry-pick a1b2c3d

when to use it

• a bugfix landed on a feature branch but main needs it now
• you committed to the wrong branch
• you need one specific commit from a long-lived branch without merging everything

cherry-pick a range

git cherry-pick a1b2c3d..e4f5g6h

this applies all commits between those two hashes (exclusive of the first one).

cherry-pick without committing

git cherry-pick --no-commit a1b2c3d

applies the changes but lets you modify them before committing. useful when the commit needs adaptation.

git clean and reset

cleaning untracked files

git clean -n    # dry run: see what would be deleted
git clean -fd   # actually delete untracked files and directories

always dry run first. git clean is destructive and not recoverable (unless the files are in your editor's undo history).

reset levels

git reset --soft HEAD~1   # undo commit, keep changes staged
git reset --mixed HEAD~1  # undo commit, keep changes unstaged (default)
git reset --hard HEAD~1   # undo commit, delete changes entirely

--soft is my go-to when i committed too early. it puts everything back in staging so i can recommit properly.

--hard is the nuclear option. use reflog if you mess this up.

advanced config

some git config options that improve daily life:

# better diff algorithm
git config --global diff.algorithm histogram

# auto-correct typos (runs after 1.5s delay)
git config --global help.autocorrect 15

# reuse recorded resolution for merge conflicts
git config --global rerere.enabled true

# always rebase on pull instead of merge
git config --global pull.rebase true

# sort branches by most recent commit
git config --global branch.sort -committerdate

# sign commits with ssh key
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

rerere

rerere stands for "reuse recorded resolution." when you resolve a merge conflict, git remembers. next time the same conflict appears (rebasing, cherry-picking), it resolves automatically.

this alone saves hours over a long-lived feature branch.

the mental model

git is not a linear timeline. it is a directed acyclic graph of snapshots. every commit points to its parent(s). branches are just pointers to commits. HEAD is a pointer to the current commit.

once you internalize this, everything clicks:

• rebase replays commits onto a new base
• merge creates a commit with two parents
• cherry-pick copies a commit's diff to a new location
• reset moves the branch pointer
• reflog records every pointer movement

the commands are just different ways of manipulating pointers and snapshots. learn the model, and the commands make themselves obvious.

-- moli

this site started as a weekend project and turned into something i actually care about. here is how every piece fits together, the decisions behind them, and the code that makes it work.

the stack

no cms, no database, no server. markdown files, static hosting, done.

the boot sequence

when you first visit the site, you see a fake bios boot screen. it is silly. it is completely unnecessary. i love it.

onMounted(() => {
    if (sessionStorage.getItem("booted")) {
        done.value = true;
        return;
    }

    const prefersReducedMotion = window.matchMedia(
        "(prefers-reduced-motion: reduce)"
    ).matches;
    if (prefersReducedMotion) {
        sessionStorage.setItem("booted", "true");
        done.value = true;
        return;
    }

    show.value = true;
    setTimeout(() => {
        show.value = false;
        sessionStorage.setItem("booted", "true");
        setTimeout(() => { done.value = true; }, 400);
    }, 2500);
});

design decisions

• runs once per session: sessionStorage means refreshing the page skips it. you only see it when you first arrive.
• respects reduced motion: if your os says you prefer reduced motion, the boot sequence is skipped entirely. accessibility is not optional.
• staggered lines: each line appears with a css animation-delay, simulating a real boot sequence. the timing is tuned to feel fast but readable.

.boot-line {
    opacity: 0;
    animation: boot-appear 0.15s ease-out forwards;
}

the progress bar fills at 1.6 seconds and the whole thing wraps up at 2.5 seconds. long enough to register, short enough to not annoy.

page transitions

every page change has a smooth fade-and-slide animation powered by motion-v (a vue port of framer motion).

import { motion, AnimatePresence } from "motion-v";

const pageEnter = { opacity: 0, y: 20 };
const pageAnimate = { opacity: 1, y: 0 };
const pageExit = { opacity: 0, y: -20 };

<router-view v-slot="{ Component, route }">
    <AnimatePresence mode="wait">
        <motion.div
            :key="route.path"
            :initial="isInitialLoad ? false : pageEnter"
            :animate="pageAnimate"
            :exit="pageExit"
            :transition="pageTransition"
        >
            <component :is="Component" />
        </motion.div>
    </AnimatePresence>
</router-view>

the subtle details

• no animation on first load: isInitialLoad ? false : pageEnter prevents the home page from sliding in when you first visit. the boot sequence handles the entrance.
• wait mode: AnimatePresence mode="wait" means the old page fades out before the new one fades in. no overlap, no jank.
• spring physics: transitions use spring-based easing instead of linear or cubic-bezier. springs feel more natural because they can overshoot slightly, like real objects.

the command palette

cmd+k opens a spotlight-style command palette. it searches pages, toggles theme, and finds blog posts.

const filteredActions = computed(() => {
    const q = query.value.toLowerCase().trim();
    const all = [
        ...pages,
        themeAction.value,
        ...blogPosts.value,
    ];

    if (!q) {
        return [
            ...pages,
            themeAction.value,
            ...blogPosts.value.slice(0, 5),
        ];
    }

    return all.filter(action =>
        action.label.toLowerCase().includes(q) ||
        action.description.toLowerCase().includes(q)
    );
});

how it works

1. global keydown listener captures cmd+k / ctrl+k
2. teleported to body so it renders above everything
3. backdrop blur creates depth without a harsh overlay
4. keyboard navigation: arrow keys move selection, enter executes, escape closes
5. auto-focus: input gets focus immediately on open

the animation

the modal slides in with a custom cubic-bezier that overshoots slightly:

.palette-modal {
    animation: modal-in 0.2s cubic-bezier(0.16, 1, 0.3, 1);
}

@keyframes modal-in {
    from {
        opacity: 0;
        transform: translateY(-8px) scale(0.96);
    }
    to {
        opacity: 1;
        transform: translateY(0) scale(1);
    }
}

the 0.2s duration is intentional. any slower and it feels sluggish for something that should feel instant. any faster and you do not see the animation at all.

markdown rendering

blog posts are plain markdown files with yaml-like frontmatter. the rendering pipeline has three stages.

stage 1: frontmatter parsing

export const parseFrontmatter = (content) => {
    const match = content.match(/^---\s*\n([\s\S]*?)\n---\s*\n([\s\S]*)$/);
    if (!match) return { frontmatter: {}, content };

    const [, frontmatterText, bodyContent] = match;
    const frontmatter = {};

    frontmatterText.split("\n").forEach((line) => {
        const [key, ...rest] = line.split(":");
        if (!key || rest.length === 0) return;
        const value = rest.join(":").trim();
        if (value.startsWith("[") && value.endsWith("]")) {
            frontmatter[key.trim()] = value
                .slice(1, -1)
                .split(",")
                .map((item) => item.trim());
        } else {
            frontmatter[key.trim()] = value;
        }
    });

    return { frontmatter, content: bodyContent };
};

no yaml parser dependency. the format is simple enough that a regex and some string splitting handles everything. arrays use bracket notation: tags: [vue, webdev, tutorial].

stage 2: markdown to html

marked.js with a custom renderer that applies catppuccin classes to every element:

heading({ tokens, depth }) {
    const text = this.parser.parseInline(tokens);
    const id = slugify(text);
    const classes = {
        1: "text-2xl font-bold text-catppuccin-text mt-8 mb-4",
        2: "text-xl font-semibold text-catppuccin-blue mt-8 mb-4",
        3: "text-lg font-semibold text-catppuccin-mauve mt-6 mb-3",
    };
    return `<h${depth} id="${id}" class="${classes[depth]}">${text}</h${depth}>`;
}

every heading gets a slugified id for anchor links. h2 headings are blue, h3 headings are mauve. this color distinction helps you scan the page visually.

stage 3: syntax highlighting

prismjs runs after the markdown is rendered and inserted into the dom:

const highlightCodeBlocks = async () => {
    await ensurePostEnhancers();
    await nextTick();
    if (PrismInstance && articleContentRef.value) {
        PrismInstance.highlightAllUnder(articleContentRef.value);
    }
};

prism is lazy-loaded. it only imports when you open a blog post, not on the home page. the language components (javascript, python, bash, css) are loaded in parallel with the main prism module.

the copy button

every code block gets a copy button that appears on hover:

code({ text, lang }) {
    const id = `code-block-${codeBlockCounter++}`;
    return `<div class="relative group">
        <button data-copy-target="${id}"
            class="absolute top-2 right-2 opacity-0
                   group-hover:opacity-100 ...">
            copy
        </button>
        <pre class="...">
            <code id="${id}" class="language-${lang}">
                ${escaped}
            </code>
        </pre>
    </div>`;
}

the button uses event delegation on the article container rather than attaching listeners to each button. one listener handles all code blocks.

the table of contents

the sticky toc sidebar is one of my favorite features. it uses intersection observer to highlight the current section as you scroll.

const extractHeadings = () => {
    const els = articleContentRef.value.querySelectorAll("h2, h3");
    headings.value = Array.from(els).map(el => ({
        id: el.id,
        text: el.textContent,
        level: parseInt(el.tagName[1]),
    }));
};

intersection observer setup

observer = new IntersectionObserver(
    (entries) => {
        entries.forEach((entry) => {
            if (entry.isIntersecting) {
                activeId.value = entry.target.id;
            }
        });

        const allAbove = entries
            .filter(e => e.boundingClientRect.top < 0)
            .sort((a, b) =>
                b.boundingClientRect.top - a.boundingClientRect.top
            );

        if (allAbove.length && !entries.some(e => e.isIntersecting)) {
            activeId.value = allAbove[0].target.id;
        }
    },
    { rootMargin: "-20% 0px -70% 0px", threshold: 0 }
);

why these margins

-20% 0px -70% 0px means the observer considers a heading "visible" when it is in the top 20-30% of the viewport. this feels right because you are reading downward — by the time a heading reaches the top third of the screen, that is the section you are in.

the fallback logic handles an edge case: when you scroll fast and no heading is currently intersecting, it picks the last heading that scrolled above the viewport.

the visual indicator

<button
    :class="[
        activeId === heading.id
            ? 'text-catppuccin-mauve border-l-2 border-catppuccin-mauve pl-2'
            : 'text-catppuccin-subtle border-l-2 border-transparent pl-2',
    ]"
>

active sections get a mauve left border and text color. h3 headings are indented. the whole thing is hidden on mobile because a sidebar toc does not make sense on small screens.

the reading progress bar

a thin mauve bar at the top of blog posts that fills as you scroll:

const updateReadingProgress = () => {
    rafId = requestAnimationFrame(() => {
        const scrollTop = window.scrollY;
        const docHeight =
            document.documentElement.scrollHeight - window.innerHeight;
        readingProgress.value =
            docHeight > 0
                ? Math.min((scrollTop / docHeight) * 100, 100)
                : 0;
    });
};

wrapped in requestAnimationFrame for performance. scroll events fire constantly, but raf ensures we only calculate once per frame.

<div class="fixed top-0 left-0 w-full h-[3px] z-[9998]">
    <div
        class="h-full bg-catppuccin-mauve"
        :style="{
            width: readingProgress + '%',
            transition: 'width 0.1s ease-out'
        }"
    ></div>
</div>

3 pixels tall. enough to notice, not enough to distract. the 0.1s transition smooths out the movement so it does not jitter on fast scrolling.

blog post loading

posts are loaded at build time using vite's glob import:

const postModules = import.meta.glob("/posts/*.md", {
    eager: true,
    query: "?raw",
    import: "default",
});

why eager loading

eager: true means all posts are bundled into the javascript. for a personal blog with 15-20 posts, this is fine — maybe 50-100kb of markdown total. the alternative (lazy loading each post) adds network requests and loading states for negligible savings.

slug generation

const slug = path.replace("/posts/", "").replace(".md", "");

the filename is the slug. building-this-site.md becomes building-this-site. no database ids, no generated hashes. rename the file, change the url.

sorting and caching

posts are sorted by date (newest first) once at load time and cached. no re-sorting on every render.

the catppuccin theme system

the entire site uses catppuccin mocha as its color system. tailwind is configured with css custom properties:

// tailwind.config.js
colors: {
    catppuccin: {
        text: "rgb(var(--color-text))",
        base: "rgb(var(--color-base))",
        crust: "rgb(var(--color-crust))",
        mauve: "rgb(var(--color-mauve))",
        blue: "rgb(var(--color-blue))",
        // ... all 26 catppuccin colors
    }
}

dark and light modes

css variables switch between mocha (dark) and latte (light):

:root {
    --color-text: 205 214 244;    /* mocha text */
    --color-base: 30 30 46;       /* mocha base */
    --color-mauve: 203 166 247;   /* mocha mauve */
}

.light {
    --color-text: 76 79 105;      /* latte text */
    --color-base: 239 241 245;    /* latte base */
    --color-mauve: 136 57 239;    /* latte mauve */
}

by using rgb values without the rgb() wrapper, tailwind can add opacity modifiers: bg-catppuccin-surface/50 becomes rgba(var(--color-surface), 0.5). this one trick makes the entire theme system work with tailwind's opacity utilities.

the 0.9 scale trick

@media (min-width: 1024px) {
    #app {
        transform: scale(0.9);
        transform-origin: center center;
        margin-top: -5vh;
    }
}

on desktop, the entire app is scaled to 90%. this makes the monospace font and terminal aesthetic feel more "contained" — like looking at a terminal window rather than a full-screen application. the negative margin compensates for the visual gap the scaling creates.

performance decisions

what i did not add

• no ssr: this is a static personal site. the spa loads fast enough. adding nuxt or ssr would triple the complexity for marginal improvement.
• no image optimization pipeline: i have maybe five images total. a build-time optimizer would be over-engineering.
• no state management: vue's ref() and computed() handle everything. pinia would be unused overhead.
• no analytics: i do not need to know how many people read my posts. the site exists because i enjoy building it.

what i optimized

• lazy prismjs: syntax highlighting only loads when viewing a blog post.
• eager post loading: all markdown bundled upfront to avoid loading spinners.
• raf-throttled scroll handlers: reading progress bar and toc use requestAnimationFrame instead of raw scroll events.
• css animations over js: boot sequence and palette animations use css keyframes. js controls when they start, css handles the motion.
• minimal dependencies: the total dependency count is under 10. every package earns its place.

what i would do differently

vue over astro

if i started today, i might consider astro with vue islands. the blog content is static — it does not need to be an spa. but honestly, the spa approach works fine for this scale and i enjoy having full control.

tailwind classes in markdown

the custom marked renderer injects tailwind classes directly into html strings. it works, but it means the markdown output is tightly coupled to tailwind. if i ever migrate away from tailwind, every renderer function needs rewriting.

a better approach would be using semantic css classes and styling them separately. but "better" and "worth refactoring" are different things.

testing

there are no tests. for a personal blog, i am fine with this. i test by looking at the site. but if this were a team project, the markdown renderer and blog service would need unit tests.

the terminal aesthetic philosophy

the whole site follows one principle: look like a terminal, behave like a website.

• ~$ cd ~/blog above the blog list — decorative, not functional
• ~$ cat post.md above post content — sets the mood
• ~$ toc above the table of contents — consistent theming
• monospace font everywhere — commitment to the bit
• left border on content — mimics a terminal cursor column

but the site still has proper links, responsive layout, smooth animations, and accessibility features. the terminal aesthetic is a skin, not a limitation.

the most important lesson from building this site: constraints breed creativity. "make it look like a terminal" sounds limiting, but it actually made every design decision easier. when you have a strong visual language, you spend less time deciding and more time building.

-- moli

isps use dpi (deep packet inspection) to analyze traffic and block certain sites. zapret bypasses these restrictions.

what we're doing

1. dns over tls setup
2. zapret installation
3. isp-specific parameter detection
4. profit

required packages

# debian/ubuntu
sudo apt install -y curl dnsutils nftables unzip

# fedora/rhel
sudo dnf install -y bind-utils curl nftables unzip

# arch
sudo pacman -S --noconfirm bind-tools curl nftables unzip

dns setup

zapret only bypasses dpi. we need to set up dns ourselves. using yandex dns here, alternatives:

• cloudflare dns (recommended)
• mullvad dns
• google dns

# enable systemd-resolved
sudo systemctl enable --now systemd-resolved

# write dns config
sudo tee /etc/systemd/resolved.conf &>/dev/null << EOF
[Resolve]
DNS=77.88.8.8#common.dot.dns.yandex.net
DNS=2a02:6b8::feed:0ff#common.dot.dns.yandex.net
DNSOverTLS=yes
EOF

# symlink resolv.conf
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# restart
sudo systemctl restart systemd-resolved

download zapret

# clean start
sudo rm -rf /tmp/zapret-v72.7*

# download and extract
sudo wget -P /tmp https://github.com/bol-van/zapret/releases/download/v72.7/zapret-v72.7.zip
sudo unzip -d /tmp /tmp/zapret-v72.7.zip
sudo rm /tmp/zapret-v72.7.zip

pre-installation

# remove old installation
sudo /opt/zapret/uninstall_easy.sh 2>/dev/null
sudo rm -rf /opt/zapret

# install requirements
sudo /tmp/zapret-v72.7/install_prereq.sh
sudo /tmp/zapret-v72.7/install_bin.sh

firewall question: leave blank (nftables will be selected)

blockcheck - isp analysis

detect the dpi method your isp uses:

sudo /tmp/zapret-v72.7/blockcheck.sh

answers:

test takes a few minutes. you'll get output like:

curl_test_https_tls12 ipv4 discord.com : nfqws --dpi-desync=fakeddisorder --dpi-desync-ttl=1 --dpi-desync-autottl=-5 --dpi-desync-split-pos=1

note the part starting with nfqws. these are your isp-specific bypass parameters.

zapret installation

sudo /tmp/zapret-v72.7/install_easy.sh

nano will open. find NFQWS_OPT and paste your blockcheck parameters:

NFQWS_OPT="--dpi-desync=fakeddisorder --dpi-desync-ttl=1 --dpi-desync-autottl=-5 --dpi-desync-split-pos=1"

save: Ctrl+S, exit: Ctrl+X

leave the remaining questions blank.

cleanup

sudo rm -rf /tmp/zapret-v72.7

done. 🎉

uninstalling

# remove zapret
sudo /opt/zapret/uninstall_easy.sh
sudo rm -rf /opt/zapret

# reset dns
sudo tee /etc/systemd/resolved.conf &>/dev/null <<< ""
sudo systemctl restart systemd-resolved

-- moli

another year of code, mistakes, and small victories.

what went well

finally shipped the personal website. it sat in drafts for 2 years. this year i stopped polishing and just released.

switched to zed full time. neovim config was a second job. not missing it.

started using chezmoi for dotfiles. should have done this 5 years ago.

what did not

too many half-finished projects. the graveyard has 7 repos with 3 commits each.

neglected the blog. 10 posts was the goal, hit 6. better than zero but not what i wanted.

numbers

github contributions: 847
repos created: 12
repos deleted: 7
blog posts: 6

2026 goals

writing

12 blog posts. one per month. topics: rust, devops, tooling, and fewer opinion pieces.

code

ship 4 cli tools. small, focused, documented.

get comfortable with rust ownership. stop fighting the borrow checker.

learning

go deeper on systems programming. currently surface level with too many languages.

health

less screen time outside of work. the eyes notice.

the plan

nothing revolutionary. just show up more consistently.

happy new year.

-- moli

using claude (and others) for code daily. here is the honest assessment.

what got faster

boilerplate: generate sql schemas, api types, test setups. 10 seconds vs 10 minutes.

searching: "how do i configure vite for multiple entry points" returns the exact config in seconds instead of digging through docs.

refactoring: "rename this function and update all call sites" across 20 files. done.

documentation: explain what this regex does, what this error means, why this type error appears.

what stayed the same

architecture: choosing between database approaches, api design patterns, library selection. llms give options but you must judge them.

debugging: weird runtime errors, race conditions, deployment failures. llms guess wrong as often as they guess right.

creative work: novel features, unique solutions, edge cases. llms remix existing patterns.

what got harder

reading code: i rely on llms to explain code. without them, i struggle to parse unfamiliar codebases.

writing from scratch: starting a project from zero feels harder because i default to "ask first" instead of "figure it out".

attention span: quick answers mean less deep thinking. sometimes you need to struggle with a problem to understand it.

the balance

i use llms for:

• repetitive tasks
• documentation lookup
• small refactors
• one-off scripts

i avoid llms for:

• security-critical code
• learning new concepts
• architectural decisions
• unfamiliar codebases

the future

the good developers will use llms as force multipliers. the bad ones will depend on them completely.

the skill is knowing when to ask and when to figure it out yourself.

-- moli

minimal, fast, keyboard-driven.

terminal

alacritty with gpu acceleration. 60fps scrolling on 4k monitors.

[font]
size = 13
offset = { y = 1 }

[window]
opacity = 0.9
decorations = "None"

no title bar, slight transparency, monospace font.

shell

zsh with oh-my-zsh stripped down.

plugins=(git python docker)

prompt is minimal:

╭─ user@host ~/project ────────────────────────────────────
╰─ $

no fortune, no cowsay, no ascii art on start.

multiplexing

tmux with prefix changed to Ctrl+a.

set -g mouse on
set -g status-style "bg=#1e1e2e"
set -g window-style "bg=#1e1e2e"
set -g pane-border-style "fg=#313244"

copy mode with mouse works. scrolling works. it feels like a gui.

the workflow

Ctrl+a + c     # new window
Ctrl+a + n     # next window
Ctrl+a + |     # horizontal split
Ctrl+a + _     # vertical split
Ctrl+a + arrow # navigate panes

all keyboard. hands never leave home row.

tools

small binaries that do one thing well.

config location

~/.config/
  alacritty/
  tmux/
  zsh/

all version controlled. chezmoi manages the sync.

-- moli

moving from javascript to rust felt like learning to code again. here is what clicked for me.

no garbage collector

in js, you forget about memory. in rust, you own it.

let mut vec = Vec::new();
vec.push("hello");

the vector owns its memory. when it goes out of scope, memory is freed. no leaks, no gc pauses.

ownership is the key

every value has one owner. when the owner is dropped, the value is dropped.

let s1 = String::from("hello");
let s2 = s1; // s1 is moved to s2
// println!("{}", s1); // error! s1 is no longer valid

this is not a reference. this is ownership transfer.

borrowing

fn calculate_length(s: &String) -> usize {
    s.len()
} // s goes out of scope but nothing is dropped

references are borrowing. you cannot modify what you borrow unless you use &mut.

the compiler is your friend

rust compiler errors are incredibly helpful:

error[E0382]: use of moved value: `vec`
   --> src/main.rs:10:13
    |
8  |     let vec = vec![1, 2, 3];
    |         --- move occurs because `vec` has type `Vec<i32>`, which does not implement the `Copy` trait
9  |     let vec2 = vec;
    |             --- value moved here
10 |     println!("{:?}", vec);
    |                     ^^^ value used after move

it tells you exactly what happened and how to fix it.

tooling

• cargo: package manager, build tool, test runner
• rustfmt: automatic formatting
• clippy: linting
• rust-analyzer: the best language server i have ever used

getting started

rustup init
cargo new my_project
cd my_project
cargo run

start small. the book is free at doc.rust-lang.org.

-- moli

github's contribution graph is iconic. i wanted it on my site without their api rate limits.

the data

github exposes contribution counts at https://github.com/users/{username}/contributions.

a quick scrape gives you the raw data in html. parsing it is straightforward:

const data = Array.from(document.querySelectorAll('.day'))
  .map(day => ({
    date: day.dataset.date,
    count: parseInt(day.dataset.count, 10)
  }))

the grid

52 weeks × 7 days = 364 squares. css grid makes this trivial:

display: grid;
grid-template-rows: repeat(7, 1fr);
grid-auto-flow: column;

this creates the left-to-right week flow with days stacked vertically.

color scale

contribution counts map to colors. catppuccin palette works well:

0: crust
1-3: base
4-6: overlay
7-9: mauve
10+: pink

interactivity

hover shows the date and count. click could link to that day's github profile.

title = `${date}: ${count} contributions`

simple and effective.

deployment

fetch on build time. cache the json. no client-side api calls, no rate limit issues.

-- moli

a 1.2gb python image for a 10mb script is ridiculous. here is how i shrank my deployments.

start small

FROM python:3.12-slim
# vs
FROM python:3.12

slim saves 800mb immediately. alpine saves more but brings libc compatibility issues.

for go binaries:

FROM scratch
COPY main /main

zero runtime dependencies. the image is just your binary.

multi-stage builds

FROM golang:1.21 AS builder
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o main main.go

FROM alpine:latest
COPY --from=builder /main /main
CMD ["/main"]

builder stage is discarded. final image contains only what runs.

tooling

• dive: inspect layer contents
• docker-slim: auto-optimize
• grype: scan for vulnerabilities in thin images

numbers

smaller images deploy faster, scan faster, and have smaller attack surfaces.

-- moli

in a world of spotify wrapped once a year, last.fm just keeps scrobbling. every single track. forever.

why last.fm in 2025?

spotify gives you stats once a year. last.fm gives you stats every second.

• real-time tracking - see what you're listening to right now
• historical data - years of listening history
• open api - actually lets you build stuff
• cross-platform - works with everything, not just spotify

the api is actually good

const response = await axios.get('https://ws.audioscrobbler.com/2.0/', {
    params: {
        method: 'user.getrecenttracks',
        user: 'yourusername',
        api_key: 'your_key',
        format: 'json',
        limit: 10
    }
});

that's it. no oauth dance. no token refresh hell. just an api key and you're good.

what you get back

• track name
• artist
• album
• album art
• timestamp
• whether it's currently playing

everything you need to show "now playing" on your site.

my setup

i added a recent tracks section to my site. updates every 30 seconds. shows what i'm listening to in real-time.

the cool part: consolidating repeat plays. if i listen to the same song 5 times in a row (no judgment), it shows ×5 instead of listing it five times.

the scrobbling ecosystem

last.fm works with basically everything:

• spotify (native)
• apple music (via apps)
• youtube music
• local files
• literally anything with a scrobbler

vs spotify wrapped

the vibe

there's something nice about having a complete record of everything you've ever listened to. not just for stats, but for the memories.

looking at my scrobbles from 2020 hits different.

add it to your site

if you're building a personal site, add your recent tracks. it's:

• easy to implement
• shows personality
• actually useful
• free api

the truth

last.fm has been doing "music tracking" since 2002. spotify wrapped is just last.fm once a year with better marketing.

real ones know.

-- moli

i tried symlinking manually. i tried git bare repo tricks. i tried ansible. chezmoi is the only one that stuck.

why it works

chezmoi is idempotent. running it twice does nothing bad. it respects $HOME and creates symlinks or copies based on your preference.

chezmoi add ~/.zshrc
chezmoi apply

that's it. no Makefile gymnastics, no stow confusion.

the templating

need different configs for work and home? chezmoi templates with sprig functions.

{{- if eq .hostname "work-laptop" }}
# work settings
{{- end }}

handles per-machine config without branching repositories.

the diff

chezmoi diff shows exactly what will change before you apply. safety net for people who fear ruining their shell config.

getting started

brew install chezmoi
chezmoi init --apply https://github.com/yourusername/dotfiles

migrate existing configs:

chezmoi add ~/.config/alacritty/alacritty.toml
chezmoi status
chezmoi apply

-- moli

after 5 years of muscle memory, i deleted my .config/nvim folder. here is what led me there.

the problem with plugins

neovim plugins are amazing until one breaks after an update. lsp configurations drift, treesitter parsers desync, and suddenly you spend a saturday debugging instead of coding.

zed has zero config out of the box. language servers just work. no PackerSync, no MasonInstallAll, no checkhealth.

the mouse thing

i thought i hated the mouse. turns out i just never had a good one.

zed's multi cursor with mouse support is faster than any vim motions for repetitive edits. select, alt+click more, type. done.

the tradeoffs

missing:

• :terminal
• :G for git (though zed's built-in git is surprisingly good)
• tmux integration

gaining:

• no startup time
• collaboration features (remote sessions are wild)
• vim mode that actually feels complete

verdict

zed is not for everyone. if you live in terminal, stick with neovim. if you want a fast editor that feels like 2025, try it for a week.

i am not looking back.

-- moli

i finally automated the thing i always complained about: moving notes from obsidian into this site without copy paste misery.

the rough edges

• obsidian makes it easy to write, hard to export.
• backlinks, custom callouts, and dataview blocks break vite builds.
• manual cleanup means i forget to publish at all.

the new flow

1. tag a note with #publish.
2. run bun run sync:notes.
3. script converts frontmatter, strips obsidian syntax, and drops the file into posts/.
4. vite hot reloads and i get instant preview.

key pieces

scripts/
  sync-notes.ts      # pulls marked notes over fs
  render-snippets.ts # converts callouts -> blockquotes

• parses the first heading for the title.
• default excerpt comes from the first paragraph.
• preserves code blocks and inline formatting.

why this setup

• fast fs operations.
• typescript without extra config.
• easy to ship a single command.

what needs polish

• images still require hand uploading.
• dataview tables get downgraded to plain lists.
• i want a diff preview before overwriting an existing post.

for now, it feels like magic compared to the old workflow. more excuses to write.

-- moli

there is something addictive about finishing a small cli tool before monday hits. no roadmap, just a scratch to itch.

the idea bank

• convert spotify playlists to mp3 tags.
• wrap openapi specs into copy pasteable markdown.
• run npm audit across multiple repos with one command.

i keep them in a todo.md file, label the ones that can be done in under 6 hours, and pick one on friday night.

constraints i set

1. only one external dependency allowed.
2. must build on macos and linux without extra steps.
3. readme and gif demo required before calling it done.

with rules in place, i avoid feature creep and focus on the happy path.

tooling

• language: go for binaries, node for scripts.
• tests: snapshot helpers with @vitest/ui for quick feedback.
• packaging: goreleaser for go, bun run build for js.

releasing

• tag v0.x.0 even if it is just a prototype.
• publish binaries on github releases.
• write a short blog post describing the problem solved.

lessons

• single purpose tools invite fewer bug reports.
• shipping early surfaces real workflows that docs ignore.
• saying "no" to extra flags keeps the interface friendly.

if i can keep this streak going, i will end the year with a neat toolbox instead of an idea backlog.

-- moli

my site looks like a shell prompt, but that does not mean i want to live in vt100 land. here is how i kept the vibe without the eye strain.

color choices

• base palette from catppuccin mocha.
• bumped contrast on text by 6 percent for accessibility.
• reserved neon colors for accents only.

typography

• jetbrains mono for everything, but with tighter letter spacing above 26px.
• headlines use uppercase sparingly to avoid shouting.
• paragraphs stay at 14px with 1.6 line height to mimic terminal proportions.

micro interactions

• focus rings get a subtle mauve outline instead of pure white.
• list animations use transition-delay to feel like commands printing.
• cards tilt between 2 and 4 degrees on hover, nodding to crt jitter.

pitfalls avoided

• no fake scanlines. they age poorly and hurt readability.
• refused to add artificial typing animations on every section.
• kept layout responsive; terminal does not mean fixed width.

tools

• tailwind for spacing and responsive helpers.
• @headlessui/vue for accessible menus (even if they look old school).
• figma variables to experiment with contrast quickly.

keeping the aesthetic light enough means i can enjoy the nostalgia while staying productive. feels like the right balance for now.

-- moli

another day, another "revolutionary ai browser" launches. it's just chromium with a sidebar. again.

the pattern

1. take chromium
2. add ai chatbot in sidebar
3. maybe throw in some "smart" features
4. call it the future of browsing
5. raise $20m

looking at you, comet. and atlas. and literally every other "ai-first" browser.

what they promise

• "revolutionary browsing experience"
• "ai-powered productivity"
• "the browser reimagined"
• "intelligent web companion"

what you get

• chromium (again)
• chatgpt/claude in a sidebar
• maybe some summarization features
• 500mb of electron bloat
• another app eating your ram

the real innovation would be

actually rethinking browsing. not just bolting ai onto the side.

ideas that would actually be interesting:

• ai that understands page structure beyond just text
• intelligent tab management that actually works
• privacy-first ai that runs locally
• new ways to navigate the web beyond urls

but no. we get chromium + sidebar. revolutionary.

why this matters

every new "browser" is just chromium. the web is becoming a monoculture. firefox is hanging on by a thread. safari exists only because apple.

and now ai browsers are making it worse by pretending a wrapper is innovation.

the sidebar problem

you know what i can do? open chatgpt in a tab. or use raycast. or literally any other tool.

putting it in a sidebar doesn't make it special. it makes it annoying.

what i actually want

give me a browser that:

• respects my ram
• doesn't track everything
• has actual innovation in navigation
• integrates ai thoughtfully, not just as a bolt-on
• isn't just chromium in a trench coat

the truth

these aren't ai browsers. they're chromium distributions with a chatbot.

stop calling it innovation. it's not. it's lazy.

real innovation would be building something new. but that's hard. wrapping chromium is easy. and vcs love easy.

-- moli

decided to start writing down my thoughts and experiences. mostly tech stuff, but also random things i find interesting.

why blog?

• document my learning journey
• share solutions to problems i've faced
• practice writing and articulating ideas
• connect with other devs

what to expect

posts about web dev, projects i'm working on, tools i discover, and occasional random thoughts. no fixed schedule - i'll write when i have something worth sharing.

thanks for reading.

-- moli