DEV Community: LazyDoomSlayer

I Don’t Blog to Teach: I Blog to Track My Own Journey

LazyDoomSlayer — Tue, 07 Apr 2026 18:30:41 +0000

You see a lot of advice around blogging as a developer.

Build your personal brand.
Grow an audience.
Share knowledge.

That’s not why I started.

The real reason

I didn’t start blogging because I forget things.
Actually, I don’t.

But that’s not the point.

What I do want is a clear view of my own roadmap, what I learned, when I learned it, and how I was thinking at that moment.

Not just final solutions.

But:

the confusion
the decisions
the small realizations
the progress over time

That’s the part you lose if you don’t write things down.

The question people asked me

When I started posting, some friends asked me:

“Why are you even writing blogs? Are you trying to impress someone?”

And honestly, I get it.

From the outside, it can look like that.

But no.

I’m not trying to impress anyone.

What blogging actually is for me

For me, blogging is simple.

It’s a way to:

track my progress
document how my thinking evolves
keep a record of what I’m building and learning

It’s basically a timeline of my developer journey.

Something I can revisit later and understand:

where I was
what I struggled with
what eventually clicked

Why this matters

As developers, we move fast.

We jump between:

tools
frameworks
problems
ideas

Even if you don’t forget things, you lose context.

You forget:

why you chose a specific approach
what confused you at the time
what changed your understanding

That context is valuable.

And that’s exactly what I want to keep.

Where this will help

Right now, I’m just getting started.

But I already know this will matter when I document things like:

my homelab setup
infrastructure experiments
my shift from frontend (Vue) into Rust and systems

Because later, I won’t just care about what I did.

I’ll care about how I got there.

Finally

So no, I’m not blogging to teach.

I’m blogging to track my own journey.

To see how I evolve over time.

If someone finds it useful along the way, that’s just a bonus.

From Vue to Rust: Why a Frontend Developer Started Writing Systems Tools

LazyDoomSlayer — Fri, 13 Mar 2026 18:46:56 +0000

Hook

After spending several years working primarily with Vue and TypeScript, I started paying closer attention to the tools that power the developer ecosystem.

While exploring modern terminal workflows and developer tooling, I kept encountering the same language again and again: Rust.

Tools like ripgrep (used for fast searching in editors like Neovim), zoxide, exa, terminal applications like lazygit, GPU-accelerated terminals like Alacritty, and TUI frameworks such as Ratatui are all part of the growing Rust ecosystem.

Beyond terminal tools, Rust is also powering projects like the Zed editor, the Biome JavaScript toolchain, and desktop frameworks like Tauri.

Seeing Rust appear across so many modern developer tools made me curious:

What would it be like for a frontend developer to start building tools in Rust?

My Background as a Frontend Developer

My professional work is mostly in the frontend ecosystem. Over the past few years I’ve been working with Vue and TypeScript, building web applications and focusing on the user-facing side of software.

Like many frontend developers, most of my tooling and scripting traditionally lived in the Node.js ecosystem. From build tools to small automation scripts, JavaScript was usually the default choice.

But over time I started becoming more interested in developer tooling itself things like CLI utilities, terminal workflows, and small system-level tools that improve everyday development.

That curiosity is what eventually led me to start exploring Rust.

Why I Decided to Try Rust

My first real reason to try Rust came from experimenting with desktop applications using Tauri.

As someone coming from the frontend world, Tauri felt like a natural bridge. I could still use web technologies for the interface, while Rust handled the system-level parts of the application. That combination made Rust feel much more approachable than jumping straight into systems programming.

After that first step, curiosity started taking over.

I began exploring other areas where Rust is commonly used building CLI tools, experimenting with terminal user interfaces using Ratatui, and generally trying to understand how Rust applications interact more closely with the system.

Several things about Rust were appealing at the same time:

Memory safety without a garbage collector
Performance of compiled binaries
The ability to produce a single standalone executable
And honestly, the challenge of learning something very different from the JavaScript ecosystem

Rust felt like a language that encouraged thinking differently about how software is structured, especially compared to the object-oriented patterns I was used to from other languages.

What Surprised Me When Learning Rust

Starting with Rust was not as smooth as learning another JavaScript framework or library.

Coming from a background where most of my experience was with object-oriented patterns and higher-level abstractions, Rust initially felt very different. Concepts like ownership, borrowing, and strict compile-time checks were confusing at first.

The shift in thinking was probably the biggest challenge. Instead of relying on runtime behavior or flexible patterns, Rust encourages you to be explicit about how data moves through your program.

At the beginning this can feel frustrating, but something interesting happens over time: the compiler starts to feel less like an obstacle and more like a guide.

Rust’s compiler is extremely strict, but it also provides detailed feedback. Many mistakes that would normally show up as runtime bugs are caught much earlier during compilation.

That experience changes how you think about writing software.

When Rust Makes Sense (and When It Doesn't)

One thing I learned while exploring Rust is that it isn’t meant to replace every tool or language in your workflow.

For example, JavaScript and TypeScript are still excellent choices for building web applications, especially when rapid development and a large ecosystem are important. In frontend development, the productivity and flexibility of the JavaScript ecosystem are hard to beat.

Rust, however, shines in slightly different areas.

Because Rust compiles to a standalone binary and focuses heavily on performance and safety, it works extremely well for things like:

CLI tools
terminal applications
developer tooling
system-level utilities
desktop applications with frameworks like Tauri

These kinds of programs often benefit from fast startup times, efficient resource usage, and strong guarantees around memory safety.

For me, Rust didn’t replace the tools I was already using it simply opened a new category of problems that I could explore and build solutions for.

Where My Rust Journey Is Going Next

Learning Rust has changed the way I think about building software.

Even though my primary work is still focused on frontend development with Vue and TypeScript, Rust introduced me to a different layer of the software stack one that is closer to the system and focused on performance, reliability, and tooling.

Right now I’m continuing to experiment with Rust by building small tools, exploring Tauri for desktop applications, and learning more about terminal user interfaces using Ratatui.

For a frontend developer, Rust might feel unfamiliar at first, but that unfamiliarity is exactly what makes the journey interesting.

Stay Rusty 🦀

run.sh Diaries #5: Make It Yours – Forking, Tweaking & Extending the Setup

LazyDoomSlayer — Thu, 12 Mar 2026 10:40:29 +0000

TL;DR
In this final post, I’ll show you how to take my Ubuntu WSL bootstrap and make it your own.

Whether you want to add dotfiles, set up Git identity, or install completely different tools, this structure makes it easy to fork, extend, and personalize.

Why Customization Matters

This project works for me, but you should own your environment.

My goal from the beginning was to make this:

Modular (each tool gets its own script)
Transparent (readable Bash, no black-box logic)
Easy to tweak (just edit configs or scripts)

This isn’t a framework, it’s a blueprint.

1. Add or Remove Packages

You can edit packages.conf to:

Add tools you always install (e.g. jq, htop, gh)
Remove things you don’t use (e.g. yazi, btop)

SYSTEM_UTILS_APT=(
  wget curl jq htop
)

DEV_TOOLS_SNAP=(
  nvim
)

These arrays are passed into helper functions from utils.sh, which handle install logic cleanly.

2. Add Your Own Scripts

To add new tooling (like Go, Deno, or Rust), follow this pattern:

Create a new file like go-setup.sh
Add install logic using apt, Snap, curl, or custom methods
Append it to the SCRIPTS=(...) array in run.sh

Example:

readonly SCRIPTS=(
  ...
  "go-setup.sh"
)

3. Include Dotfiles or Shell Config

Want to bootstrap your .bashrc, .tmux.conf, or .gitconfig?

You can:

Clone your dotfiles repo in a new dotfiles-setup.sh
Symlink them or append to existing configs
Set aliases, functions, or themes

This is also a good place to add default Git config, like:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

4. Handle Secrets and Git Identity

Avoid committing private tokens or configs. Instead:

Keep a local ~/.local-setup.sh script with personal logic
Add .local-setup.sh to your .gitignore
Source it at the end of run.sh (if it exists)

if [ -f "$HOME/.local-setup.sh" ]; then
  echo "Running local custom setup..."
  bash "$HOME/.local-setup.sh"
fi

5. WSL-Specific Optimizations

Some tweaks worth adding if you run WSL full time:

Create a .wslconfig on Windows for better resource limits
Add mounts or performance tweaks in /etc/wsl.conf
Disable unnecessary services that don’t apply in WSL

You can even add a WSL check to run.sh:

grep -qi microsoft /proc/version && echo "Running under WSL"

Fork It, Extend It, Own It

This whole project is meant to be cloned, forked, and hacked.
Start with mine, and make it match your exact stack and preferences.
If you build something cool from this, I’d love to see it.

Final Recap

Over the last 5 posts, you’ve seen how I:

Automated my WSL Ubuntu setup from scratch
Wrote modular Bash scripts with smart defaults
Bootstrapped a full terminal dev stack
Installed Node, Python, and Docker with zero hassle
Built a foundation that anyone can extend

Takeaway?

Automate the boring stuff, personalize the rest, and keep improving it.

run.sh Diaries #4: From Zero to Coding-Ready with Node, Python & Docker

LazyDoomSlayer — Tue, 03 Mar 2026 14:00:56 +0000

TL;DR
This post covers how my WSL bootstrap sets up Node.js, Python, and Docker and the core tools I use for frontend, backend, scripting, and container work.
Each tool has its own setup script, designed to be modular, idempotent, and fast.

Why These Tools?

My day-to-day work (and open source projects) span across:

Frontend apps (Vue, Nuxt, TypeScript)
Scripts, automation, CLI tools (Python)
Testing infrastructure, running services, and debugging (Docker)

So my bootstrap includes all of them by default and no more grabbing install commands from old gists or StackOverflow every time I set up WSL.

Node.js Setup – `node-setup.sh`

I install Node.js LTS (v22) using nvm because it's the most flexible method for switching versions.

What the script does:

Installs or updates NVM
Loads it into the shell
Installs Node.js v22 and sets it as default
Installs global tools: pnpm and yarn
Disables Yarn telemetry

Why this approach?

Versioning via NVM makes switching Node versions trivial
I use pnpm for speed and monorepos, and yarn where needed

nvm install 22
npm install -g pnpm yarn

Output is printed to verify versions and check everything succeeded.

Python Setup – `python-setup.sh`

Python is everywhere and whether I’m scripting quick tools, using CLI apps, or running data scripts.

What this setup covers:

Installs Python via APT
Installs pip, venv, and upgrades setuptools, wheel, etc.
Prepares the environment for creating isolated Python workspaces

This setup is intentionally minimal and just enough to bootstrap Python for development, automation, and further customization.

Docker Setup – `docker-setup.sh`

I use Docker for containers when testing services or building isolated environments.

What the script does:

Installs Docker via APT (using official repo)
Adds the current user to the docker group (so no need for sudo)
Enables the Docker service

Why this matters:

WSL2 supports Docker with great performance
You shouldn’t have to use sudo to run docker in dev environments

Docker is optional, but including it makes the bootstrap future-proof if I need containers down the line.

One Bootstrap to Install Them All

All of these are automatically set up when I run:

./run.sh

I don’t have to worry about:

Which method to use (nvm, APT, Snap, curl?)
Forgetting steps like adding users to Docker groups
Repeating things across different machines

Future Improvements

Things I might add later:

Version pinning via .nvmrc or .tool-versions
Python virtualenv examples (or Poetry setup)
Docker Compose install

Next: Make It Yours

In run.sh Diaries #5, I’ll show you how to:

Add your own scripts
Customize package lists
Include dotfiles or Git config
Extend the bootstrap for your own stack

run.sh Diaries #3: My Terminal Stack – tmux, zoxide, and lazygit

LazyDoomSlayer — Tue, 24 Feb 2026 07:45:26 +0000

TL;DR
This post walks through the terminal tools I bootstrap with my WSL setup: tmux for multitasking, zoxide for lightning-fast directory switching, and lazygit for painless Git management.
These aren’t just cool tools and they’re essentials in my terminal-first workflow.

Why a Terminal Stack?

I’ve said it before: I prefer a terminal-first workflow.

Modern IDEs? Too heavy.
GUI Git clients? Slow and mouse-driven.
I want speed, control, and tools that work over SSH, WSL, or raw Linux.

So I built my environment around powerful CLI tools that:

Launch instantly
Don’t eat memory
Let me work efficiently in any shell or session

Let’s break down the tools I install automatically via my bootstrap scripts.

tmux – Terminal Multiplexing

tmux lets me split one terminal into multiple panes and windows. I use it to:

Run multiple shells or logs side-by-side
Persist sessions even after closing the terminal
Combine editor + server + shell in one view

Why I love it:

Clean, scriptable config
Always available in headless setups
Works beautifully with neovim, fzf, and my dotfiles

TPM – Tmux Plugin Manager

My tpm-setup.sh script installs TPM (Tmux Plugin Manager) which makes installing and updating tmux plugins painless. It lives in ~/.tmux/plugins.

`zoxide `– Smarter` cd`

zoxide is a fast, smarter alternative to cd. You just type:

z GitHub
z os-bootstraps

…and it jumps to your most-used directories.

Why I use it:

Tracks recent paths automatically
Works across shells
Insanely efficient once you get used to it

lazygit – Git, But Better

lazygit is a TUI-based Git interface I use daily to:

Switch branches
Stage/commit
Resolve merge conflicts
Review logs and diffs

It’s keyboard-first, extremely fast, and integrates perfectly into a tmux workflow.

All of These Are Auto-Installed

Once I run:

./run.sh

My terminal stack: tmux, zoxide, lazygit, neovim, and more is ready to go. No more downloading, aliasing, or reconfiguring things manually.

Next: Languages and Containers

In run.sh Diaries #4, I’ll walk you through how I set up:

Node.js with NVM
Python environments
Docker with user group access

And how it all ties into real-world frontend + backend dev work.

run.sh Diaries #2: The Bash Behind the Bootstrap

LazyDoomSlayer — Tue, 17 Feb 2026 07:54:15 +0000

TL;DR

In this post, I’ll walk through the internal logic of how my WSL bootstrap works and let’s focus on run.sh, utils.sh, and packages.conf. You’ll learn how I made the setup modular, safe to re-run, and easy to extend.

The Big Picture

In Part 1, I talked about why I built this and now let’s explore how it works.

At the heart of it is a simple philosophy:

Don’t repeat yourself.

Don’t install what’s already there.

Keep everything scriptable and modular.

The setup revolves around three key components:

run.sh – the orchestrator
utils.sh – helper functions
packages.conf – what to install

Let’s break each down.

1. `run.sh` – The Orchestrator

This script is the entry point of the whole bootstrap.

Responsibilities:

Define the list of setup scripts to run
Execute them one by one
Log their progress
Fail fast if something breaks

Structure:

readonly SCRIPTS=(
  "node-setup.sh"
  "rust-setup.sh"
  "docker-setup.sh"
  "lazygit-setup.sh"
  "python-setup.sh"
  "zoxide-setup.sh"
  "tmux-config-setup.sh"
  "tpm-setup.sh"
  "nvim-setup.sh"
)

Each script is passed into the run_script() function from utils.sh, which:

Checks if the file exists
Makes it executable
Runs it and logs its completion

2. `utils.sh` – The Bash Toolkit

This file contains reusable helpers that keep the logic clean and DRY.

Key Functions:

`is_installed_apt` / `is_installed_snap`

Check if a package is already installed before trying to install it.

  dpkg-query -W -f='${Status}' "$1" 2>/dev/null | grep -q "install ok installed"

`install_apt_packages` / `install_snap_packages`

Take a list of packages, filter out the ones already installed, and install only what’s needed.

Includes logic to:

Run apt-get update only if required
Handle Snap not being installed
Try both normal and -classic Snap installs

`die`

A simple exit-on-error function to fail cleanly and loudly.

die() {
  echo "ERROR: $*" >&2
  exit 1
}

In the future, I plan to add features like color-coded logging, verbosity levels, timestamps, and WSL detection. But for now, the current setup does exactly what I need: simple, readable, and effective.

3. `packages.conf` – Centralized Package List

This is where all core APT and Snap packages are defined and grouped by category for clarity.

Example:

SYSTEM_UTILS_APT=(
  wget curl fzf build-essential fd-find ripgrep
)

DEV_TOOLS_SNAP=(
  nvim
)

Each package list is passed into the installer functions in utils.sh.

This structure makes it easy to:

Add/remove tools cleanly
See what’s included at a glance
Extend with new categories later

Why This Structure Works

Modularity: each setup script does one job
Reusability: helpers prevent duplication
Clarity: it’s easy to understand what gets installed and how
Safety: checks prevent reinstalling or breaking existing tools

Want to Try It?

⚠️Security Reminder

Never run scripts from the internet — including mine — without reading and understanding them first.
Even if you trust the source, it's good practice to inspect any Bash script before executing it.

I care about security too and my WSL bootstrap project is open source, transparent, and written to be as readable and modular as possible. Fork it, inspect it, tweak it.

git clone https://github.com/LazyDoomSlayer/os-bootstraps
cd os-bootstraps/ubuntu
chmod +x run.sh
./run.sh

Install time: ~5 minutes on a VM with 8GB RAM, 8-core CPU, and 50Mbps connection.

First-time runs may take longer if your system hasn’t been updated with apt-get update && upgrade.

Everything else happens automatically. Grab a coffee. ☕

What’s Next: The CLI Stack

In Part 3, I’ll show you the terminal tools I bootstrap like tmux, zoxide, lazygit, and neovim and how they fit into my daily workflow.

Want to go full terminal-first? This next part is for you.

run.sh Diaries #1: Automating My Ubuntu Dev Environment

LazyDoomSlayer — Sun, 08 Feb 2026 16:05:44 +0000

TL;DR
I got tired of setting up WSL manually across multiple machines and installing Node, Python, Docker, CLI tools, and tweaking configs. So I built a Bash-based bootstrap project that installs and configures everything I need in one go.

Checkout GitHub repo here: https://github.com/LazyDoomSlayer/os-bootstraps

Now I just run ./run.sh on a fresh Ubuntu WSL install, drink coffee ☕, and get coding in minutes. This post explains why I built it and how you can adapt it too.

Introduction - Why I Built This Ubuntu WSL Bootstrap

WSL gives me a fast Linux dev environment on Windows without needing full VMs and is perfect for scripting, Docker, and open source tooling.

I’m a frontend developer turned full-stack builder with over 3 years of experience. I split my time between product development, open source contributions, and deep dives into infrastructure, CLI tools, and automation. My current stack revolves around JavaScript/TypeScript, Vue, and increasingly Rust, Python, and TUI/GUI apps.

Outside of work, I’m building and maintaining my open source projects, experimenting with Rust tooling, and working with CLI-first workflows. That’s where Ubuntu on WSL comes in, it's my daily dev environment for Node.js projects, scripting, Rust tools, and even light container work.

But here’s the thing...

I got really tired of setting it all up. Over and over.

The Problem - Setup Fatigue

Despite having plenty of memory and a modern machine, I prefer a terminal-first workflow tmux, neovim, and CLI tools, because modern IDEs often feel bloated and sluggish.

I use WSL every day, but:

I have multiple devices (laptop, workstation, test VMs)
I often test out different config setups
And every time I reinstall Ubuntu or start fresh, I waste 1–2 hours manually installing packages, tweaking configs, and setting up tools

It's the same repetitive process: install APT packages, tweak shell config, add Node, Python, Docker, plugins...

Honestly? I'd rather drink ☕coffee and let the machine set itself up.

The LazyDev Solution

Eventually I asked myself:

“Why the hell am I not automating this?”

So I did. And because I go by LazyDoomSlayer, I took the lazy-but-smart route. I built a modular run.sh bootstrap using Bash.

This was my first real-world Bash scripting project outside of university coursework, and it solved two big problems at once:

Helped me automate something I do frequently
Helped me learn Bash scripting through practical use

The Result

Now I can spin up a clean, fully bootstrapped Ubuntu WSL dev box in minutes with my exact terminal stack, dev tools, and config with just by running:

./run.sh

Takeaway?

Automate once. Save hours later. Learn by doing.
Drink coffee while it runs.

What’s Next: The Bash Behind the Bootstrap

In Part 2, I’ll show you internal logic how my WSL bootstrap works.

DEV Community: LazyDoomSlayer

I Don’t Blog to Teach: I Blog to Track My Own Journey

The real reason

The question people asked me

What blogging actually is for me

Why this matters

Where this will help

Finally

From Vue to Rust: Why a Frontend Developer Started Writing Systems Tools

Hook

My Background as a Frontend Developer

Why I Decided to Try Rust

What Surprised Me When Learning Rust

When Rust Makes Sense (and When It Doesn't)

Where My Rust Journey Is Going Next

run.sh Diaries #5: Make It Yours – Forking, Tweaking & Extending the Setup

Why Customization Matters

1. Add or Remove Packages

2. Add Your Own Scripts

3. Include Dotfiles or Shell Config

4. Handle Secrets and Git Identity

5. WSL-Specific Optimizations

Fork It, Extend It, Own It

Final Recap

run.sh Diaries #4: From Zero to Coding-Ready with Node, Python & Docker

Why These Tools?

Node.js Setup – node-setup.sh

What the script does:

Why this approach?

Python Setup – python-setup.sh

What this setup covers:

Docker Setup – docker-setup.sh

What the script does:

Why this matters:

One Bootstrap to Install Them All

Future Improvements

Next: Make It Yours

run.sh Diaries #3: My Terminal Stack – tmux, zoxide, and lazygit

Why a Terminal Stack?

tmux – Terminal Multiplexing

Why I love it:

TPM – Tmux Plugin Manager

`zoxide – Smarter cd`

Why I use it:

lazygit – Git, But Better

All of These Are Auto-Installed

Next: Languages and Containers

run.sh Diaries #2: The Bash Behind the Bootstrap

The Big Picture

1. run.sh – The Orchestrator

Responsibilities:

Structure:

2. utils.sh – The Bash Toolkit

Key Functions:

is_installed_apt / is_installed_snap

install_apt_packages / install_snap_packages

die

3. packages.conf – Centralized Package List

Example:

Why This Structure Works

Want to Try It?

What’s Next: The CLI Stack

run.sh Diaries #1: Automating My Ubuntu Dev Environment

Introduction - Why I Built This Ubuntu WSL Bootstrap

The Problem - Setup Fatigue

The LazyDev Solution

The Result

Takeaway?

What’s Next: The Bash Behind the Bootstrap

Node.js Setup – `node-setup.sh`

Python Setup – `python-setup.sh`

Docker Setup – `docker-setup.sh`

`zoxide `– Smarter` cd`

1. `run.sh` – The Orchestrator

2. `utils.sh` – The Bash Toolkit

`is_installed_apt` / `is_installed_snap`

`install_apt_packages` / `install_snap_packages`

`die`

3. `packages.conf` – Centralized Package List