Pre-flight Checklist

Before touching the droplet, confirm:

• Cookiecutter Django project generated locally with production = Docker, Traefik (or Nginx), Postgres, and your email backend of choice (Mailgun, SendGrid, Anymail, etc.)

• Project pushed to a private GitHub repo

• Domain registered with DNS access

• DigitalOcean account ready

• Local SSH keypair (~/.ssh/id_ed25519) ready

• All .envs/.production/* files prepared locally (these are git-ignored and must be transferred separately)

Required env files:

.envs/.production/.django
.envs/.production/.postgres

Generate strong values for DJANGO_SECRET_KEY, DJANGO_ADMIN_URL, POSTGRES_PASSWORD, etc:

python -c "import secrets; print(secrets.token_urlsafe(64))"

1. Spin Up the Droplet

• Image: Ubuntu 24.04 (LTS) x64

• Plan: Basic — minimum 2 GB RAM / 1 vCPU. Postgres + Django + Traefik + Redis on 1 GB will OOM during builds.

• Auth: SSH key (paste your ~/.ssh/id_ed25519.pub)

• Region: Closest to your users

• Hostname: something descriptive (e.g. myapp-prod-sg1)

Note the public IPv4 once it's provisioned.

2. DNS Records

In your domain registrar (or DigitalOcean DNS):

Traefik will provision Let's Encrypt SSL automatically once DNS resolves and ports 80/443 are open. Wait for DNS to propagate before bringing up the stack — otherwise Let's Encrypt will rate-limit you on failed challenges.

dig yourdomain.com +short

3. Initial Server Hardening

Connect as root

ssh root@<droplet_ip>

Update packages

apt update && apt upgrade -y

Create a non-root user

Replace <username> with your chosen username throughout this guide.

adduser <username>
usermod -aG sudo <username>

Mirror SSH keys to the new user

rsync --archive --chown=<username>:<username> ~/.ssh /home/<username>

Configure UFW

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Port 80 needs to be open (not just 443) because Traefik uses it for the Let's Encrypt HTTP-01 challenge and to redirect HTTP traffic to HTTPS.

Reconnect as the new user

exit
ssh <username>@<droplet_ip>

Lock down SSH

sudo nano /etc/ssh/sshd_config

Set:

PermitRootLogin no
PasswordAuthentication no

Reload SSH (no full reboot needed):

sudo systemctl reload ssh

Test from a new terminal before closing the current session — if you locked yourself out, the live session is your only way back in.

4. Install Docker & Compose Plugin

# Remove any old versions
sudo apt remove -y docker docker-engine docker.io containerd runc

# Install dependencies
sudo apt install -y ca-certificates curl gnupg lsb-release

# Add Docker's GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repo
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Allow your user to run docker without sudo
sudo usermod -aG docker $USER
newgrp docker

# Verify
docker --version
docker compose version

5. Set Up GitHub Deploy Key

Since the repo is private, the droplet needs SSH access to clone and pull.

ssh-keygen -t ed25519 -C "<username>@yourdomain.com"
# Press enter through prompts (no passphrase, default location)
cat ~/.ssh/id_ed25519.pub

Copy the output and add it as a deploy key on the GitHub repo:

Settings → Deploy keys → Add deploy key

Read-only access is fine unless you're pushing from the server.

Test the connection:

ssh -T git@github.com

6. Clone the Project

cd ~
git clone git@github.com:<your-username>/<your-repo>.git
cd <your-repo>

7. Transfer Production Env Files

The .envs/.production/ folder is git-ignored, so SCP it from local:

From your local machine:

scp -r .envs/.production <username>@<droplet_ip>:~/<your-repo>/.envs/

Verify on the droplet:

ls -la ~/<your-repo>/.envs/.production/
# Should show .django and .postgres

Lock down permissions:

chmod 600 ~/<your-repo>/.envs/.production/.django
chmod 600 ~/<your-repo>/.envs/.production/.postgres

8. Configure Production Domain

Update .envs/.production/.django

nano .envs/.production/.django

Critical variables:

DJANGO_ALLOWED_HOSTS=yourdomain.com,www.yourdomain.com
DJANGO_SECURE_SSL_REDIRECT=True
DJANGO_SERVER_EMAIL=noreply@yourdomain.com
DJANGO_DEFAULT_FROM_EMAIL=hello@yourdomain.com
MAILGUN_API_KEY=<key>
MAILGUN_DOMAIN=mg.yourdomain.com

Update compose/production/traefik/traefik.yml

nano compose/production/traefik/traefik.yml

Replace every instance of the placeholder domain with yours. Look for:

- "Host(`example.com`) || Host(`www.example.com`)"

And the Let's Encrypt email:

email: "your_real_email@yourdomain.com"

Use a real, monitored email — Let's Encrypt sends expiry warnings here.

9. Build and Launch

docker compose -f docker-compose.production.yml up --build -d

First build takes 5–10 minutes. Watch logs:

docker compose -f docker-compose.production.yml logs -f

What to look for:

• traefik should successfully obtain Let's Encrypt cert (search logs for certificate obtained)

• django should boot without import errors

• postgres should be ready and accepting connections

Common first-run failures:

• Cert acquisition fails → DNS hasn't propagated yet, or port 80 is blocked

• Django can't connect to DB → .envs/.production/.postgres mismatch

• 502 from Traefik → Django container crashed, check logs django

10. Run Migrations & Create Superuser

# Migrations
docker compose -f docker-compose.production.yml run --rm django python manage.py migrate

# Superuser
docker compose -f docker-compose.production.yml run --rm django python manage.py createsuperuser

# Collect static (usually handled at build time, but run if needed)
docker compose -f docker-compose.production.yml run --rm django python manage.py collectstatic --noinput

Never run makemigrations on the server. Generate migrations locally, commit them, pull on the server, then migrate.

11. Update the Sites Framework

Cookiecutter Django uses Django's Sites framework (especially for django-allauth email links). Update the default site:

docker compose -f docker-compose.production.yml run --rm django python manage.py shell

from django.contrib.sites.models import Site
site = Site.objects.get(pk=1)
site.domain = "yourdomain.com"
site.name = "Your App"
site.save()
exit()

12. Smoke Test

• https://yourdomain.com loads with valid SSL (no warnings)

• https://yourdomain.com/<DJANGO_ADMIN_URL>/ → admin login works

• Sign up flow → confirmation email arrives

• Password reset email arrives

• Static files serving (CSS/JS load, no 404s in DevTools)

• http://yourdomain.com redirects to https://

13. Updating Deployments

For subsequent deploys:

cd ~/<your-repo>
git pull
docker compose -f docker-compose.production.yml up --build -d
docker compose -f docker-compose.production.yml run --rm django python manage.py migrate

If you changed env vars, restart the django service:

docker compose -f docker-compose.production.yml restart django

14. Backups

Cookiecutter Django ships with a backup command for Postgres:

# Create backup
docker compose -f docker-compose.production.yml exec postgres backup

# List backups
docker compose -f docker-compose.production.yml exec postgres backups

# Restore (replace with actual backup filename)
docker compose -f docker-compose.production.yml exec postgres restore backup_2026_05_09T00_00_00.sql.gz

Add a cron job for daily backups + offsite sync to S3 / DO Spaces:

crontab -e

0 3 * * * cd /home/<username>/<your-repo> && docker compose -f docker-compose.production.yml exec -T postgres backup >> /home/<username>/backup.log 2>&1

15. Troubleshooting Cheatsheet

16. Next Steps (Optional Hardening)

• CI/CD: GitHub Actions workflow → SSH into droplet → git pull && docker compose up --build -d. Use repo secrets for the SSH key.

• Monitoring: Sentry (already wired in Cookiecutter Django) + Uptime Robot for external checks.

• Logs: Ship to a service (Logtail, Papertrail, Datadog) instead of relying on docker logs.

• Secrets management: Move from .env files to Doppler, Infisical, or DO's encrypted env vars for team workflows.

• Database: Move Postgres off the droplet to DO Managed Postgres once you have real traffic. Update DATABASE_URL and you're done.

• CDN: Serve static/media from DO Spaces + a CDN edge.

Wrapping Up

Your Django app should now be live behind HTTPS, with auto-renewing SSL, a hardened server, and a clear path for future deploys and backups. From here, the obvious next investments are CI/CD, observability, and moving your database to a managed service once traffic justifies it.

This guide walks through a clean, system-level way to automatically connect or disconnect Cloudflare WARP depending on your WiFi network name (SSID) using NetworkManager on Linux.

🧠 Why This Matters

Not all networks are equal:

• 🏠 Trusted WiFi (Home) → You may not need WARP

• ☕ Public WiFi → You definitely want WARP

• 🏢 Office networks → Might conflict with VPN routing

Instead of manually toggling WARP every time, we can hook into network state changes and automate it.

⚙️ How It Works

Linux systems using NetworkManager support dispatcher scripts—these are triggered automatically when network events occur (e.g., connecting to WiFi).

We leverage this to:

1. Detect the current SSID

2. Apply conditional logic

3. Toggle WARP accordingly via CLI

🔧 Step-by-Step Implementation

1. Ensure WARP CLI is Installed

You should already have warp-cli available. If not, install Cloudflare WARP first.

Then register and test:

warp-cli register
warp-cli connect
warp-cli status

2. Create a NetworkManager Dispatcher Script

Dispatcher scripts live here:

/etc/NetworkManager/dispatcher.d/

Create a new script:

sudo nano /etc/NetworkManager/dispatcher.d/99-warp-toggle

3. Add Logic Based on SSID

Paste the following:

#!/bin/bash

INTERFACE="$1"
STATUS="$2"

# Trigger only when a connection is established
if [ "$STATUS" = "up" ]; then
    SSID=$(iwgetid -r)

    if [ "$SSID" = "home_wifi" ]; then
        echo "Connecting WARP for $SSID"
        warp-cli connect

    elif [ "$SSID" = "office_wifi" ]; then
        echo "Disconnecting WARP for $SSID"
        warp-cli disconnect

    else
        echo "Unknown network: $SSID — no action taken"
    fi
fi

4. Make the Script Executable

sudo chmod +x /etc/NetworkManager/dispatcher.d/99-warp-toggle

5. Apply Changes

Restart NetworkManager:

sudo systemctl restart NetworkManager

Or simply reconnect your WiFi.

🧪 Testing

Switch between your networks:

• Connect to home_wifi → WARP should connect

• Connect to office_wifi → WARP should disconnect

Verify with:

warp-cli status

⚠️ Things to Watch Out For

• SSID detection relies on iwgetid — ensure it’s installed

• Dispatcher scripts run as root, so be careful with permissions and logging

• Some networks may block WARP traffic, causing connection failures

• Avoid adding too many rapid toggles (though WARP CLI is fairly tolerant)

🧩 Optional Enhancements

If you want to level this up:

🔹 Add Logging

echo "\((date): Connected to \)SSID" >> /var/log/warp-toggle.log

🔹 Handle More Networks

Expand your conditions into a case statement:

case "$SSID" in
  "home_wifi")
    warp-cli connect
    ;;
  "office_wifi")
    warp-cli disconnect
    ;;
esac

🔹 Default Behavior

Set a fallback (e.g., always connect WARP unless explicitly disabled)

💡 Final Thoughts

This approach is powerful because it’s:

• Event-driven (no polling loops)

• Lightweight (no extra services needed)

• Extensible (you can hook in more automations)

You’re essentially turning your machine into a context-aware system—reacting intelligently to its environment.

Once you get comfortable with dispatcher scripts, this pattern opens up a lot of automation possibilities beyond VPNs.

If you’re building out a more advanced workflow system (especially with tools like n8n or custom daemons), this can serve as a solid foundation for network-aware automation.

🚀

If you've ever watched your free disk space quietly shrink over a few weeks of active development, you know the feeling: yesterday you had plenty of headroom, today your IDE is yelling about low disk space, and you have no idea what ate the difference. Active Node.js and Python projects are especially good at this — node_modules, build caches, .next directories, virtual environments, and compiled artifacts accumulate silently with every install and every build.

This article walks through a bash script, find_largest_files.sh, that scans a directory tree and writes the largest files to a timestamped text report. It's designed to be a first diagnostic tool when you're trying to answer the question "where did all my disk space go?"

The script at a glance

The full script is in find_largest_files.sh. Here's what it does, step by step:

1. Takes three optional arguments: search directory, number of results, and output filename.

2. Validates that the search directory exists and that the count is a positive integer.

3. Writes a header to the output file with timestamp, host, user, and scan parameters.

4. Uses find to list every regular file under the target directory, along with its size in bytes.

5. Sorts the list numerically by size (largest first), takes the top N, and converts byte counts into human-readable units (K/M/G/T).

6. Appends the formatted list to the report and prints it to your terminal.

Key design decisions

Using find -printf instead of ls or du

find "$SEARCH_DIR" -type f -printf '%s\t%p\n'

find -printf outputs size (%s) in bytes and the full path (%p), tab-separated. This matters for three reasons: byte-level precision means sorting stays accurate; tab separation survives filenames with spaces; and restricting to -type f means we report on actual files, not directory aggregates the way du would.

Pruning pseudo-filesystems

\( -path /proc -o -path /sys -o -path /dev -o -path /run -o -path /snap \) -prune

/proc, /sys, /dev, and /run are kernel-provided virtual filesystems. They contain "files" whose reported sizes are often meaningless (a /proc/kcore can appear to be 128 TB). /snap is pruned because snap mount points produce duplicate entries. Skipping all five keeps the report focused on real files on your actual disk.

Silencing permission errors

2>/dev/null

On a full / scan, find will hit directories your user can't read and print Permission denied for every one of them — noise that can bury the real output. Redirecting stderr to /dev/null cleans that up. Run the script with sudo if you want complete coverage.

Human-readable sizes in awk, not find

We sort the raw byte counts first, then format them in awk. If we formatted early (e.g. via find ... | sort -h), we'd either give up precision or depend on sort -h parsing variants. Keeping bytes for sorting and converting after is simpler and portable.

Running it against your scenario

You mentioned roughly 30 GB of disk disappeared recently while you've been building mortgage_system and mortgage_frontend with Claude. Those kinds of projects are classic sources of silent disk bloat. Here's how I'd approach the investigation.

Step 1: Get the big picture

Start at root to confirm whether the missing space is actually inside your project folders, or somewhere else entirely (logs, Docker, snap revisions, trash, etc.).

sudo ./find_largest_files.sh / 50 full_scan.txt

This gives you the 50 biggest files system-wide. If most of them are under /home/you/mortgage_system/... or /home/you/mortgage_frontend/..., your instinct was right. If the top entries are elsewhere — /var/lib/docker, /var/log, ~/.cache, snap backups — the real culprit is somewhere you weren't looking.

Step 2: Focus on the suspects

Once you've confirmed the project folders are the problem, narrow the scan:

./find_largest_files.sh ~/mortgage_system 30 mortgage_system_report.txt
./find_largest_files.sh ~/mortgage_frontend 30 mortgage_frontend_report.txt

Step 3: Check directory-level size too

Individual largest files tell one story; directory totals tell another. A million tiny files in node_modules won't show up in a largest-files report, but they'll still eat gigabytes. Pair the script with du:

du -h --max-depth=1 ~/mortgage_system | sort -rh | head -20
du -h --max-depth=1 ~/mortgage_frontend | sort -rh | head -20

Common culprits in active dev folders

Based on the stack you're likely using, here are the usual suspects, roughly in order of how often they're the answer:

• node_modules/ — routinely 500 MB to 2 GB per project. Two full Next.js/React projects with heavy dependency trees can easily account for 3–5 GB each.

• .next/ or dist/ or build/ — production builds and incremental build caches. Next.js's .next/cache in particular can grow to several GB over weeks of npm run dev.

• .git/ — if you've committed large binaries or have a long history, .git/objects can be surprisingly fat. git gc --aggressive helps.

• Python __pycache__/ and .venv/ — virtual environments with ML/data dependencies (torch, tensorflow, pandas) are often 3–8 GB each.

• Docker layers — /var/lib/docker is the single most common "where did my disk go?" answer on dev machines. docker system df shows the breakdown; docker system prune -a reclaims it.

• Log files — /var/log/journal/, application logs, and PM2 logs can grow indefinitely if no rotation is configured.

• Snap revisions — Ubuntu keeps old snap versions by default. sudo snap set system refresh.retain=2 caps retention at two revisions.

• Trash — ~/.local/share/Trash/ is easy to forget.

• Browser caches — ~/.cache/google-chrome, ~/.cache/mozilla, and similar can hit several GB.

For Node projects specifically, a quick sanity check:

du -sh ~/mortgage_system/node_modules ~/mortgage_frontend/node_modules 2>/dev/null

If each is over a gigabyte, that's your ~30 GB budget explained between two projects, their build caches, and a .git folder or two.

Useful companion commands

# Overall disk usage at a glance
df -h

# Top-level directories sorted by size (run from /)
sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

# What's eating your home directory
du -h --max-depth=1 ~ | sort -rh | head -20

# Docker-specific
docker system df
docker system prune -a --volumes  # aggressive, frees everything unused

# Clean npm cache
npm cache clean --force

# Clean pip cache
pip cache purge

# Clear systemd journal older than 7 days
sudo journalctl --vacuum-time=7d

Going further: ncdu for interactive exploration

The script gives you a static report, which is great for archiving and diffing over time. For interactive drilling, install ncdu:

sudo apt install ncdu
ncdu ~

It gives you a terminal UI where you can navigate directories by size, delete things on the spot, and generally understand disk usage faster than any CLI combination. It's the tool I reach for once the script points me to the neighbourhood and I need to find the exact house.

Setting up ongoing monitoring

If you want to catch disk bloat as it happens instead of after the fact, schedule the script via cron and diff the reports:

# Edit your crontab
crontab -e

# Add: run every Sunday at 2 AM, save to a reports directory
0 2 * * 0 /home/you/find_largest_files.sh / 50 /home/you/disk_reports/scan_$(date +\%Y\%m\%d).txt

A week later, diff two reports to see what grew.

Resources

• GNU findutils manual — find — authoritative reference for find, including the full -printf format spec.

• Linux du man page — directory-aggregate sizing, the natural complement to this script.

• Linux df man page — filesystem-level free space.

• ncdu home page — interactive disk usage analyzer.

• Docker: prune unused objects — official guide to reclaiming Docker space.

• npm cache documentation — how npm's cache works and how to clean it.

• Ask Ubuntu: Why is my disk full? — community thread with many alternative one-liners.

• Arch Wiki: Disk usage analyzers — concise overview of CLI and GUI tools across the Linux ecosystem.

Summary

If the script points at node_modules and .next inside your two mortgage projects, that's consistent with the 30 GB of lost disk — two mature JS/TS codebases with their build artifacts can account for exactly that range. The usual remediation is rm -rf node_modules .next in each project, followed by a fresh npm install only on the one you're actively working on. If instead the biggest files live under /var/lib/docker or /var/log, the fix is completely different, which is exactly why running a scan first beats guessing.

Hi Ice, now that we pushed the changes sa site, we need to scour the site for mentions of Level 1, Level 2, Level 1/2 and change them accordingly to Level 1 → Intro to Neurofascial Training, Level 1/2 → Intermediate Instability Training, Level 2 → Advanced Neurofascial Training

On the surface, this looks like a simple find-and-replace job. Read the message, open the WordPress admin, use the search feature, fix each page. Done before lunch.

Then I actually opened the site and pulled the sitemap. 1,074 URLs.

That changes the math pretty quickly. Even if only a fraction of those pages mention "Level" anywhere, manually clicking through every post and page, ctrl-F-ing for three different strings, and then figuring out which instance needs which replacement — that's a full day of soul-crushing work at minimum, and a very real chance of missing something.

The mapping

Before anything else, I wrote the rename table down somewhere I couldn't lose it, because a misread mapping here would mean renaming correct text into incorrect text, which is strictly worse than leaving it alone:

The important ordering detail: "Level 1/2" has to be matched before "Level 1", or a naive find-and-replace would turn "Level 1/2" into "Intro to Neurofascial Training/2". Easy to miss, painful to undo.

Why not just use WordPress search-replace plugins?

Plugins like Better Search Replace do exist, and in a simpler world I'd use one. But they operate on the database directly, which means:

1. One wrong checkbox and you nuke every "Level 1" across post content, post meta, widget text, theme options, and anywhere else the phrase appears — including places it shouldn't be replaced, like analytics or audit logs.

2. There's no preview of where each match lives. You're trusting the plugin's count and hoping nothing weird is hiding in a shortcode.

3. The three strings overlap, so the order of operations matters and plugins don't always let you sequence replacements atomically.

What I actually wanted was a map — a list of every occurrence with enough surrounding context to judge whether it's safe to change, plus a direct link to the WordPress editor for that specific page. The replacement itself I'd still do by hand, but informed by real data.

The script

I wrote a Python script that walks the site's sitemap, visits each URL, and searches the rendered HTML for the three patterns using a single regex with word boundaries:

LEVEL_PATTERN = re.compile(
    r"\bLevel\s*1\s*/\s*2\b|\bLevel\s*1\b|\bLevel\s*2\b",
    re.IGNORECASE,
)

Word boundaries matter here. Without \b, a page mentioning "Level 10" or "Level 12-week program" would get flagged as a false "Level 1" match. And the alternation order mirrors the mapping problem above — "Level 1/2" is tried first so it doesn't get shadowed by the simpler "Level 1" pattern.

For each match, the script captures:

• The page URL and <title>

• The WordPress post ID, extracted from the <body> class (WP adds page-id-123 or postid-123 automatically)

• A direct admin edit link built from that ID: /wp-admin/post.php?post=123&action=edit

• About 80 characters of context on either side of the match

• The HTML tag wrapping the match (h2, li, p, etc.) to help me find it inside the block editor

All of it dumped to a CSV. Rows sorted, duplicates within a page collapsed, system paths like /wp-admin and /wp-json filtered out so the scanner doesn't waste time on pages that aren't user content.

What the CSV actually gives me

Instead of 1,074 pages to click through blindly, I now have a focused list of every page that mentions "Level" in any form, with a one-click link to the editor and enough context to know which replacement to apply. The context column is the real magic — I can see a snippet like …our flagship Level 1 class is held every Tuesday… and immediately know it's the class name that needs to become "Intro to Neurofascial Training", not some incidental use of the word "level".

For the rare edge case — a page that mentions "Level 1" in a way that shouldn't be renamed, like historical text or a testimonial quoting someone — I can spot it in the context column and skip that row. That judgment call is exactly the part you don't want a blind database replacement making on your behalf.

Takeaway

The temptation with a task like this is to just start clicking. It feels productive. But on a site of any real size, a half hour spent writing a scanner pays for itself almost immediately — not just in saved time, but in the confidence that you actually caught everything and didn't quietly corrupt adjacent content along the way.

Sometimes the most valuable thing automation gives you isn't speed. It's the audit trail.

References

• New XML Sitemaps Functionality in WordPress 5.5 — Make WordPress Core: https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/

• Sitemaps XML Protocol — sitemaps.org: https://www.sitemaps.org/protocol.html

• body_class() Function Reference — WordPress Developer Resources: https://developer.wordpress.org/reference/functions/body_class/

• get_body_class() Function Reference — WordPress Developer Resources: https://developer.wordpress.org/reference/functions/get_body_class/

• re — Regular expression operations — Python 3 docs: https://docs.python.org/3/library/re.html

• Better Search Replace — WordPress Plugin Directory: https://wordpress.org/plugins/better-search-replace/

• Requests: HTTP for Humans — https://requests.readthedocs.io/

• Beautiful Soup Documentation — https://www.crummy.com/software/BeautifulSoup/bs4/doc/

This guide walks you through creating a full file backup of your WordPress site directly from the server using the command line.

Installing the Required Tools

Before connecting to your server, make sure the necessary tools are installed on your local machine.

macOS

macOS comes with ssh and scp pre-installed. No action needed — just open Terminal and you're ready to go.

Linux (Ubuntu/Debian)

sudo apt update && sudo apt install openssh-client

Windows

Option A — Windows Subsystem for Linux (WSL) (recommended):

wsl --install

Once WSL is set up, ssh and scp are available inside the Linux shell.

Option B — OpenSSH via PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

After installing, ssh and scp will be available directly in PowerShell or Command Prompt.

Option C — GUI alternative: Install WinSCP for a drag-and-drop interface to transfer files instead of using scp.

On the Server

Your server should already have tar and mysqldump available. If for any reason they are missing, install them with:

# tar
sudo apt install tar          # Debian/Ubuntu
sudo yum install tar          # CentOS/RHEL

# mysqldump (part of the MySQL client)
sudo apt install mysql-client          # Debian/Ubuntu
sudo yum install mysql                 # CentOS/RHEL

Prerequisites

Before you begin, make sure you have:

• SSH access to your server

• The server's IP address

• Your SSH credentials (username and password, or an SSH key)

• scp or an SFTP client installed on your local machine

Step 1: SSH Into Your Server

Open your terminal and connect to your server using SSH. Replace ip_address with your actual server IP:

ssh root@ip_address

You'll be prompted for your password (or authenticated via SSH key). Once connected, you'll be inside your server's shell.

Tip: If you're using a non-root user, replace root with your username (e.g., ssh deploy@192.168.1.100).

Step 2: Create a Compressed Archive of Your Site

Your WordPress files typically live inside the public_html directory. The following command creates a compressed .tar.gz archive of the entire folder:

tar -czvf ~/public_html/backup-site.tar.gz -C ~/ public_html

What each flag does:

The backup file backup-site.tar.gz will be saved inside ~/public_html/.

Note: Depending on your site size, this may take a few minutes. Large media libraries will increase the archive size significantly.

Step 3: Download the Backup to Your Local Machine

Once the archive is created, exit the SSH session and run the following scp command on your local machine to download the backup:

scp root@ip_address:~/public_html/backup-site.tar.gz ~/Downloads/

This securely copies the file from your server to your local ~/Downloads/ folder.

Tip: If you're on Windows, you can use WinSCP or the built-in scp command in PowerShell/WSL as an alternative.

Step 4: Don't Forget the Database

A full WordPress backup requires both the files and the database. Your files backup covers themes, plugins, and uploads — but your posts, pages, and settings live in MySQL.

To export your database, run this on the server:

mysqldump -u root -p your_database_name > ~/public_html/backup-db.sql

Then download it the same way:

scp root@ip_address:~/public_html/backup-db.sql ~/Downloads/

Replace your_database_name with the database name found in your wp-config.php file.

Step 5: Clean Up the Server

To avoid using up disk space on your server, delete the backup files after downloading them:

rm ~/public_html/backup-site.tar.gz
rm ~/public_html/backup-db.sql

Restoring from a Backup

To restore, simply reverse the process:

1. Upload the .tar.gz file back to the server using scp

2. Extract it with:

   tar -xzvf backup-site.tar.gz -C ~/
   

3. Import the database with:

   mysql -u root -p your_database_name < backup-db.sql
   

Final Thoughts

Manual backups via SSH are reliable, fast, and give you a portable snapshot of your entire site. For production sites, consider automating this process with a cron job or combining it with offsite storage like S3 or Google Drive.

A backup you never tested is a backup you can't trust — make sure to do a test restore at least once.

On March 31, 2026, a high-profile supply chain attack targeted Axios, a critical HTTP client for the JavaScript ecosystem. By hijacking a maintainer's NPM account, attackers injected a malicious dependency, plain-crypto-js, which deployed a cross-platform Remote Access Trojan (RAT).

Incident Summary

Technical Deep Dive

The attack bypassed standard security audits by hiding the malicious logic within a sub-dependency. Once installed via a standard npm install, the payload scanned the host machine for:

• Environment Variables: .env files and active shell exports.

• Auth Tokens: ~/.npmrc and ~/.aws/credentials.

• SSH Keys: Unprotected private keys in ~/.ssh.

Data was exfiltrated via POST requests to the sfrclak.com Command & Control (C2) server.

Remediation & Verification

To ensure a development environment is sanitized, the following protocol was executed:

1. Network Sinkholing: Manually mapping the C2 domain to 127.0.0.1 in /etc/hosts to prevent further exfiltration and "kill" the phone-home capability.

2. Lockfile Audit: Scanning all local projects for traces of the malicious package using a space-safe search:

   Bash

   find . -type f \( -name "package-lock.json" -o -name "yarn.lock" \) -print0 | xargs -0 grep "plain-crypto-js"
   

3. Environment Sanitization: Clearing the global NPM cache and updating tool managers (like mise) to ensure only verified versions are used moving forward.

[!TIP]

Pro-Tip: Always use npm audit or tools like Snyk to monitor your dependency tree for "hidden" sub-dependencies that do not appear directly in your package.json.

While this makes sense for consecutive tutorials ("Part 1", "Part 2"), it’s significantly less ideal for ongoing series—like my "Learning how to code with AI" series—where readers typically want to see your newest breakthroughs or the latest problem you solved directly at the top of the feed.

Unfortunately, looking at the Hashnode GraphQL Schema (Series.posts), there isn't an out-of-the-box sort: RECENT parameter available. Instead, it demands that you sequentially traverse the cursor paginations starting from the oldest post you've written in that series.

Here's how I solved this issue on my React/Vite portfolio to seamlessly deliver a newest-first reading experience to my users.

The Problem: Oldest First Pagination

By default, the standard query to fetch series posts looks like this:

query Series(\(host: String!, \)slug: String!, \(first: Int!, \)after: String) {
  publication(host: $host) {
    series(slug: $slug) {
      posts(first: \(first, after: \)after) {
        edges {
          node {
            slug
            title
            publishedAt
          }
        }
        pageInfo { endCursor hasNextPage }
      }
    }
  }
}

This returns standard edge/node responses, but starting with the very first post of the series. To get the newest post to display on page 1 of our UI, we need the end of the dataset instead of the beginning.

The Solution: A Client-Side Cache & Array Reversal

Since Hashnode API's first parameter maxes out at 20 items per request, we can't simply request first: 1000 and reverse it in one go. We need to sequentially buffer the entire series.

To keep it blazing fast for users querying consecutive pages, we shouldn't fetch the whole thing from scratch every time they click "Next". Instead, we can introduce a local caching mechanism in our code.

We'll parse through all the posts via a while loop on the initial page load, cache the fully assembled series, .reverse() the data natively in JavaScript, and handle React's generic cursor logic over our local cache instead!

Re-writing fetchSeries in TypeScript

Here's my updated lib/hashnode.ts:

import { BlogPost, BlogSeries, PageInfo } from '../types';

// Let's declare local caches outside the function
const seriesMetaCache: Record<string, Omit<BlogSeries, 'posts'>> = {};
const seriesPostsCache: Record<string, BlogPost[]> = {};

export async function fetchSeries(
  slug: string,
  first = 9,
  after?: string
): Promise<{
  series: BlogSeries & { posts?: { edges: { node: BlogPost }[]; pageInfo: PageInfo } };
} | null> {

  // 1. If no 'after' is provided, we must be loading the series for the first time.
  // We'll hit the Hashnode API repeatedly until we traverse all oldest-first pages.
  if (!after || !seriesPostsCache[slug]) {
    let allPosts: BlogPost[] = [];
    let hasNextPage = true;
    let endCursor: string | undefined = undefined;
    let seriesMeta: Omit<BlogSeries, 'posts'> | null = null;

    while (hasNextPage) {
      const data: any = await gqlFetch(SERIES_QUERY, {
        host: PUBLICATION_HOST,
        slug,
        first: 20,
        after: endCursor
      });

      const publishedSeries = data.publication.series;
      if (!publishedSeries) return null;

      // Persist metadata on the first run
      if (!seriesMeta) {
        const { posts, ...metaRest } = publishedSeries;
        seriesMeta = metaRest;
      }

      const posts = publishedSeries.posts;
      allPosts = allPosts.concat(posts.edges.map((e: any) => e.node));

      hasNextPage = posts.pageInfo.hasNextPage;
      endCursor = posts.pageInfo.endCursor;
    }

    // 2. Here's the magic trick. Reverse the array so Newest is First.
    seriesPostsCache[slug] = allPosts.reverse();
    if (seriesMeta) {
      seriesMetaCache[slug] = seriesMeta;
    }
  }

  // 3. Grab from cache
  const allPosts = seriesPostsCache[slug];
  const seriesMeta = seriesMetaCache[slug];
  if (!seriesMeta) return null;

  // 4. Implement local slicing based on the provided cursors
  const startIndex = after ? allPosts.findIndex(p => p.slug === after) + 1 : 0;

  // Safety net in case of invalid cursor
  const validStartIndex = startIndex > 0 ? startIndex : (after ? allPosts.length : 0);

  const slice = allPosts.slice(validStartIndex, validStartIndex + first);
  const nextHasNextPage = validStartIndex + first < allPosts.length;

  // Set the newest 'endCursor' for the client to use on consecutive requests
  const newEndCursor = slice.length > 0 ? slice[slice.length - 1].slug : null;

  // 5. Structure exactly how the calling React component expects
  return {
    series: {
      ...seriesMeta,
      posts: {
        edges: slice.map(node => ({ node })),
        pageInfo: {
          endCursor: newEndCursor || '',
          hasNextPage: nextHasNextPage
        }
      }
    } as any
  };
}

Why this approach is awesome:

1. Zero UI Adjustments: The React component responsible for consuming the posts (SeriesPage.tsx) doesn’t even know this under-the-hood wizardry is occurring. It passes first and after standardly and receives seamless newest-first data.

2. Instant "Load More": Once the initial batch is traversed during while(hasNextPage), it acts exactly like an instant static array. Any subsequent "Load More" clicks don't hit the standard network stack; they instantly slice through seriesPostsCache in micro-seconds!

3. Overcoming GraphQL Limitations: Sometimes headless CMS or GraphQL servers (like Hashnode's otherwise fantastic API) restrict complex filtering or sorting on nested nodes purely for their own database performance. When you abstract that layer on your backend caching structure, you win full control back.

Now, whenever users visit the series pages in my portfolio, the most recently solved programming challenges are rightfully spotlighted at the very top. What's not to love about building digital experiences that slap?

In this article, I'll walk through the architecture, the backend implementation, and how to handle protected routes securely on the client side.

The Architecture Stack

Here is what we are working with:

• Backend: Django, Django REST Framework (DRF), and djangorestframework-simplejwt.

• Frontend: React (via Vite) and the newly released React Router v7.

• Styling: Tailwind CSS.

• State Management: React Context API for lightweight auth state handling.

The Goal

1. A user registers.

2. The user logs in. They receive a short-lived access token and a refresh token.

3. The backend knows if the user has completed their profile setup (is_onboarded).

4. If they haven't onboarded, the backend middleware blocks API requests, and the frontend automatically reroutes them to the /onboarding page.

5. Once onboarded, new tokens are issued with the updated status, and the user gains full access to the application /.

1. Setting up the Django Backend

The Custom User Model

First, we need to track whether a user has finished setting up their profile. We extend Django's AbstractUser:

# users/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    is_onboarded = models.BooleanField(default=False)

Customizing the JWT Payload

By default, SimpleJWT only includes the user_id inside the token. We want the frontend to immediately know the user's name and onboarding status without making an extra API call.

# users/serializers.py
from rest_framework_simplejwt.serializers import TokenObtainPairSerializer

class MyTokenObtainPairSerializer(TokenObtainPairSerializer): 
    @classmethod 
    def get_token(cls, user): 
        token = super().get_token(user) 
        # Inject custom claims into the JWT payload 
        token['is_onboarded'] = user.is_onboarded 
        token['username'] = user.username 
        return token

Enforcing Onboarding with Middleware

We want to strictly prevent un-onboarded users from accessing core application data. We do this via a custom Django middleware that intercepts requests.

# users/middleware.py
from django.http import JsonResponse
from django.urls import reverse

class OnboardingMiddleware: 
    def init(self, get_response): 
        self.get_response = get_response
    def call(self, request): 
        # Exempt authentication and onboarding endpoints 
        exempt_urls = [reverse('token_obtain_pair'), '/api/onboard/submit/', '/api/register/']
        if request.path in exempt_urls or request.path.startswith('/admin/'):
            return self.get_response(request)

        user = request.user
        # Block access if authenticated but not onboarded
        if user.is_authenticated and not user.is_onboarded:
            return JsonResponse({
                "error": "ONBOARDING_REQUIRED",
                "message": "Please complete onboarding before accessing this resource."
            }, status=403)
        return self.get_response(request)

Now, even if a user tries to bypass the frontend routing, the API will refuse to serve them data!

Refreshing Tokens upon Onboarding

When the user submits the onboarding form, their status changes in the database. However, their physical JWT won't update automatically. We handle this by issuing completely new tokens in the onboarding response:

# users/views.py
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status, permissions

class OnboardSubmitView(APIView):
    permission_classes = (permissions.IsAuthenticated,)

    def post(self, request):
        user = request.user
        if user.is_onboarded:
            return Response({"detail": "Already onboarded."}, status=400)
        
        user.is_onboarded = True
        user.save()

        # Generate fresh tokens reflecting the new state
        refresh = MyTokenObtainPairSerializer.get_token(user)
        
        return Response({
            "detail": "Onboarding complete.", 
            "is_onboarded": True,
            "access": str(refresh.access_token),
            "refresh": str(refresh)
        }, status=status.HTTP_200_OK)

2. Setting up the React Frontend

We spun up the frontend using React Router v7's built-in Vite template.

Bypassing CORS locally

To avoid CORS issues during development, we configured Vite to proxy /api requests to our Django dev server:

// vite.config.ts
import { defineConfig } from "vite";

export default defineConfig({
  // plugins...
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8000',
        changeOrigin: true,
      }
    }
  }
});

Global Authentication Context

We use React Context to provide user data (token, user payload, login, logout) globally.

A critical detail: Server-Side Rendering (SSR). React Router v7 utilizes SSR by default when hydrating the app. If you try to read localStorage.getItem('access_token') immediately on the server, Node.js will crash with a ReferenceError: localStorage is not defined.

We fix this by waiting for hydration on the client using a simple useEffect:

// app/contexts/AuthContext.tsx
import React, { createContext, useContext, useEffect, useState } from 'react';

// ... interfaces and parseJwt helper ...

export function AuthProvider({ children }: { children: React.ReactNode }) {
  const [token, setToken] = useState<string | null>(null);
  const [isClient, setIsClient] = useState(false);

  // Safe SSR hydration
  useEffect(() => {
    setIsClient(true);
    setToken(typeof window !== "undefined" ? localStorage.getItem('access_token') : null);
  }, []);

  const user = token ? parseJwt(token) as UserPayload : null;

  useEffect(() => {
    if (token) localStorage.setItem('access_token', token);
    else localStorage.removeItem('access_token');
  }, [token]);

  const login = (access: string, refresh: string) => {
    localStorage.setItem('refresh_token', refresh);
    setToken(access);
  };

  if (!isClient) return null; // Prevent hydration mismatch

  return (
    <AuthContext.Provider value={{ token, user, login, logout, refreshAccessToken }}>
      {children}
    </AuthContext.Provider>
  );
}

Route Protection and Redirection

With our context in place, protecting routes and enforcing onboarding becomes incredibly simple. We intercept users in a useEffect on our page components.

Here is what our protected Home Dashboard looks like:

// app/routes/home.tsx
import { useEffect } from "react";
import { useNavigate } from "react-router";
import { useAuth } from "../contexts/AuthContext";

export default function Home() {
  const { token, user, logout } = useAuth();
  const navigate = useNavigate();

  useEffect(() => {
    if (!token) {
      navigate("/login");               // Kick out unauthenticated users
    } else if (user && !user.is_onboarded) {
      navigate("/onboarding");          // Kick out un-onboarded users
    }
  }, [token, user, navigate]);

  // Don't render until verified to prevent brief flashes of content
  if (!user || !user.is_onboarded) return null;

  return (
    <div>
      <h1>Welcome to your portal, {user.username}!</h1>
    </div>
  );
}

When the user is pushed to /onboarding, they hit our submit button. The API returns the new tokens, we update the context, and React Router instantly pushes them back to / seamlessly!

// Inside Onboarding component submit handler
const handleComplete = async () => {
  const res = await fetch("/api/onboard/submit/", {
    method: "POST",
    headers: { "Authorization": `Bearer ${token}` }
  });
  if (res.ok) {
    const data = await res.json();
    login(data.access, data.refresh); // Instantly updates global context
    navigate("/");                    // Redirect to dashboard
  }
};

Conclusion

By embedding the is_onboarded claim directly inside the JWT, we eliminate the need for the frontend to constantly ping the database to check a user's status. Coupling this tightly with Django Middleware ensures backend security, while utilizing React Context provides snappy, seamless redirects on the frontend.

Building auth doesn't have to be painful—with the right architecture, it can be safe, scalable, and a great experience for the end user.

You do a quick search for "free audio to text transcriber" and find dozens of online tools. But there's a catch. Once you upload your file, you're hit with a paywall: "File size exceeds limit" or "Upgrade to pro to transcribe more than 60 minutes."

I recently ran into this exact problem. I needed a reliable video and audio transcriber that didn't complain when I threw a massive, multi-hour file at it. After hitting limits on almost every online service, I realized the best solution wasn't to pay for a subscription I'd rarely use—it was to build it myself.

Here is how I built my own unlimited, completely free, and private transcriber using Python, OpenAI's Whisper, and Streamlit, accelerated by NVIDIA's CUDA.

The Tech Stack

I wanted the tool to be simple to use, run locally (so my data stays private), and handle both audio and video files flawlessly. Looking at my requirements.txt, here are the core tools making it possible:

1. Python: The backbone of the project.

2. Streamlit (v1.55): A fantastic library that turns Python scripts into interactive web apps in minutes. No HTML/CSS needed.

3. OpenAI's Whisper: An incredibly powerful and accurate open-source speech recognition model that runs locally.

4. PyTorch & NVIDIA CUDA (cu12): To make the transcription lightning-fast, I included torch along with NVIDIA dependencies like nvidia-cudnn-cu12 and nvidia-cublas-cu12. This allows Whisper to harness GPU acceleration, slashing transcription times down from hours to mere minutes.

5. MoviePy (v2.2): To handle video files seamlessly by extracting the audio tracks before passing them to Whisper.

6. python-docx & fpdf2: To allow exporting the final transcriptions into easily shareable Word documents and PDFs.

How It Works

The magic of the application lies in its simplicity. Here is the life cycle of a transcription task in the app:

1. Handling the Uploads

Using Streamlit's file_uploader, I built a quick UI that accepts various formats. Streamlit makes this incredibly easy with surprisingly few lines of code:

st.title("🎙️ Audio & Video Transcriber")
st.write("Upload a file to convert speech to text.")

uploaded_file = st.file_uploader(
    "Choose a file",
    type=["mp3", "wav", "m4a", "mp4", "mov", "avi"]
)

2. Extracting Audio from Video

Whisper transcribes audio. But often, the content we want to transcribe is locked inside a video format (like a recorded Zoom meeting). To solve this, I integrated MoviePy. If the user uploads a video file, the app intercepts it, extracts the audio track in the background, and forwards that to the AI model:

# If it's a video, extract the audio using MoviePy 2.0 syntax
if suffix.lower() in [".mp4", ".mov", ".avi"]:
    st.text("Processing video... extracting audio.")
    video = VideoFileClip(input_path)
    audio_path = input_path.replace(suffix, ".mp3")

    # Access audio and write it to a temp file
    video.audio.write_audiofile(audio_path, logger=None)
    processing_path = audio_path
    video.close() # Important to free up system resources

3. GPU-Accelerated Transcription

The heavy lifting is done by Whisper. I opted to use the base model, which provides a fantastic balance between transcription speed and accuracy.

Because Whisper runs locally on my machine utilizing PyTorch and my NVIDIA GPU via CUDA, there are no time limits. I can feed it a 3-hour podcast, and it will methodically transcribe the entire thing without ever asking me for a credit card.

To make the app snappy and avoid reloading massive AI weights on every action, I used Streamlit's @st.cache_resource decorator:

# Initialize Whisper model, caching it to avoid reloading
@st.cache_resource
def load_model():
    # Use "base" for a good balance of speed and accuracy
    return whisper.load_model("base")

model = load_model()

def transcribe_file(file_path):
    st.info("Transcribing... This may take a few minutes.")
    result = model.transcribe(file_path)
    return result['text']

4. Exporting the Results

A block of text on a web page is great, but a downloadable file is better. I used python-docx to generate Word documents formatting the output nicely. Once the transcription is done, the app provides shiny download buttons right there in the UI:

def save_as_docx(text, filename):
    doc = Document()
    doc.add_heading('Transcription', 0)
    doc.add_paragraph(text)
    doc.save(filename)
    return filename

# In the Streamlit UI later...
docx_file = "transcription.docx"
save_as_docx(transcript, docx_file)
with open(docx_file, "rb") as f:
    col1.download_button("Download as DOCX", f, file_name="transcription.docx")

The Result

In less than 100 lines of Python code, I built a fully functional, local web app that solves a very real, very annoying problem.

No file size limits. No hidden paywalls. Total privacy. Blazing fast GPU inference.

Building your own tools to solve personal bottlenecks is one of the most rewarding parts of knowing how to code. If you find yourself fighting against the limitations of "free" online software, take a step back and ask yourself: "Could I just build this?"

Chances are, with modern libraries and a spare afternoon, you entirely can.

Code can be found here: https://github.com/reyesvicente/audio-to-text

Built with a sleek, glowing-green terminal aesthetic that screams "hacker culture," this new iteration brings the addictive "buy low, sell high" gameplay loop into the modern era using Next.js, React, and Tailwind CSS. Let's dive into what makes this browser adaptation so relentlessly playable.

The Vibe: Neon Green on Pitch Black

The moment you initialize your connection by entering your alias (Heisenberg, anyone?), you're greeted with a UI that perfectly captures the nostalgia of MS-DOS prompts and old-school BBS interfaces. The glowing green text (text-green-500 for the Tailwind fans), monospaced fonts, and clean, modular layout make the game feel instantly familiar yet highly polished.

It doesn’t rely on flashy 3D graphics; instead, it uses a sharp, text-heavy dashboard enriched by beautifully minimal icons from lucide-react. The real tension comes from the numbers ticking up—and plummeting down—on your screen.

Gameplay Mechanics: Survive and Thrive

The premise remains faithfully brutal. You have 30 days to make as much money as possible while dodging the cops, dealing with shady characters, and paying off a massive debt to a relentless Loan Shark.

Here are the core features that drive the simulation:

🎭 The Metro Manila Market

You travel across infamous Metro Manila locations like Tondo, Maharlika (Taguig), Tramo, Caloocan, Makati, and Quezon City. Each time you hop on a jeepney or the MRT, a day passes, and the market shifts. Prices for commodities—ranging from Weed to Methamphetamine and high-stakes Cocaine—fluctuate wildly. You might encounter a market crash flooding the streets with cheap product, or a massive police bust that skyrockets prices, giving you the perfect opportunity to offload your stash.

💼 Inventory & Risk Management

Your inventory isn't a magical bottomless bag; it's a trenchcoat. Space is severely limited, meaning you have to think critically about whether to buy cheap, bulky items or invest in expensive, space-efficient commodities. Occasionally, random events might bless you with a shady character offering a trenchcoat upgrade—for a steep price, of course.

🏦 Financial Strategy

Money management is the true heart of the game:

• The Loan Shark: You start in a deep $5,500 hole with a punishing 10% daily interest rate. Paying this off early is crucial, or the compounding interest will bury you.

• First National Bank: Don't want to carry all your cash around the dangerous subways? Stash it in the bank. It earns a safe 5% daily interest, turning the late game into a pure financial optimization puzzle.

🚔 Random Encounters

The streets of '98 Metro Manila are unpredictable. A 15% chance of a cop chase keeps you on your toes forcing you to decide whether to Run (risking a fine and damage) or Fight (risking massive health loss). Muggings can suddenly wipe out your hard-earned cash, highlighting the importance of utilizing the bank.

Under the Hood: The Modern Tech Stack

What makes this iteration so impressive is how it leverages modern web technologies to deliver a flawless, client-side experience.

• Framework: The app is powered by Next.js 15 and React 19, giving it lightning-fast state updates and a component-driven architecture.

• Styling: Tailwind CSS handles the retro aesthetic, utilizing custom glow shadows (drop-shadow-[0_0_10px_rgba(34,197,94,0.8)]) and animated pulses to bring the terminal to life.

• State Persistence: Custom React hooks (useGameState) tightly couple the game logic with the browser's localStorage, ensuring you never lose your progress if you accidentally close the tab.

• AI Integration readiness: While the core loop is deterministic, the project ships with the @google/genai SDK, hinting at potential future updates featuring LLM-driven complex events or dynamic NPC dialogue.

Final Verdict

This browser-based reimagining proves that great game loops don't age. By stripping away modern excesses and leaning hard into a highly optimized, stylized dashboard, this version of DrugLord delivers pure, unadulterated dopamine. The tension of holding onto a stash while waiting for a price spike, only to get mugged on the jeepney to Malabon, is as thrilling as ever.

If you have a spare 15 minutes, step into the terminal, watch the market, and see if you can beat the high score. Just remember to pay the Loan Shark first.

Check it out at https://drugs.vicentereyes.org

Today, we're solving a popular string manipulation problem: Longest Common Prefix.

The Problem

The goal is to write a function that finds the longest common prefix among a list of strings.

• A prefix is a substring that occurs at the beginning of a string.

• The function should return the longest common string that all words in the list start with.

• If there is no common prefix, it should return an empty string "".

Examples:

• longest_common_prefix(['flower', 'flow', 'flight']) → Should return 'fl'

• longest_common_prefix(['dog', 'racecar', 'car']) → Should return "" (no common prefix)

• longest_common_prefix(['interspecies', 'interstellar']) → Should return 'inters'

The Solution

Here is the Python implementation:

def longest_common_prefix(strings):
    """
    Finds the longest common prefix among a list of strings.
    """
    # Check for empty or invalid input
    if not strings:
        return ""

    # Set the first string as the initial prefix
    prefix = strings[0]

    # Iterate through the remaining strings
    for s in strings[1:]:
        # Shorten the prefix until it matches the start of the current string
        while not s.startswith(prefix):
            prefix = prefix[:-1]
            # If the prefix becomes empty, there is no common prefix
            if prefix == "":
                return ""

    return prefix

# Test cases
print(longest_common_prefix(['flower', 'flow', 'flight']))      # 'fl'
print(longest_common_prefix(['dog', 'racecar', 'car']))         # ''
print(longest_common_prefix(['interspecies', 'interstellar']))  # 'inters'

Code Breakdown

Let's walk through the code line by line:

1. def longest_common_prefix(strings):

   • Defines a function named longest_common_prefix that takes a list of words (strings) as input.

2. if not strings:

   • Checks if the input list is empty or None.

   • If it is empty, we return an empty string "".

   • Note: This is a safer and more Pythonic check than strings is None or strings == 0 limit cases!

3. prefix = strings[0]

   • Sets our initial assumption: let's assume the entire first string is the common prefix.

4. for s in strings[1:]:

   • Iterates through each subsequent string (s) in the list.

   • strings[1:] is Python slice notation that means "all elements from index 1 to the end".

5. while not s.startswith(prefix):

   • Keeps running as long as the current string s doesn't start with our assumed prefix.

   • .startswith() checks if a string begins with the specified prefix.

6. prefix = prefix[:-1]

   • Removes the last character from the prefix to make it shorter.

   • prefix[:-1] is string slicing that takes all characters except the last one.

7. if prefix == "":

   • If we've removed all characters from the prefix, it means the current word shares no common letters at the beginning with our initial assumed prefix.

   • We immediately return "" as we know there is no common sequence.

8. return prefix

   • Once we've successfully compared our prefix against all strings, the remaining shortened string is safely our longest common prefix!

Example Walkthrough

Let's trace the function with longest_common_prefix(['flower', 'flow', 'flight']):

1. Initialization:

   • Start with prefix = 'flower'

2. Compare with 'flow' (First iteration):

   • 'flow' doesn't start with 'flower'? True.

   • Remove last char: prefix = 'flowe'

   • 'flow' doesn't start with 'flowe'? True.

   • Remove last char: prefix = 'flow'

   • 'flow' doesn't start with 'flow'? False. Stop while loop.

   • Current prefix is safely 'flow'.

3. Compare with 'flight' (Second iteration):

   • 'flight' doesn't start with 'flow'? True.

   • Remove last char: prefix = 'flo'

   • 'flight' doesn't start with 'flo'? True.

   • Remove last char: prefix = 'fl'

   • 'flight' doesn't start with 'fl'? False. Stop while loop.

   • Current prefix is safely 'fl'.

4. Result: Loop completes, return 'fl'. ✅

Now let's try longest_common_prefix(['dog', 'racecar', 'car']):

1. Initialization:

   • Start with prefix = 'dog'

2. Compare with 'racecar':

   • 'racecar' doesn't start with 'dog'? True. Shorten to prefix = 'do'

   • 'racecar' doesn't start with 'do'? True. Shorten to prefix = 'd'

   • 'racecar' doesn't start with 'd'? True. Shorten to prefix = ""

3. Result: Prefix is empty "". Immediate return "". ❌ No common prefix found.

Key Optimizations

This approach relies heavily on Horizontal Matching:

• Shrinking Search Pattern: Instead of checking letter by letter precisely (vertical scaling index-by-index), we start by assuming the maximum possible prefix and aggressively peel off letters from the end whenever mismatches are found.

• Early Escape: If the prefix shrinks to an empty string at any point, we completely abort without iterating through the rest of the array strings.

This pattern is highly effective, easy to read, and simple to reason out! 🚀

Happy coding! 💻

You check the API payload, and it's serving a stale list of posts. The new post is completely missing.

I spent hours debugging this, trying every cache-busting trick in the book. Here's what didn't work, why it failed, and the actual simple solution.

The Setup

My portfolio runs on React (Vite) and uses Hashnode as a headless CMS. I fetch posts using fetch with the official Hashnode GraphQL endpoint: https://gql.hashnode.com.

const res = await fetch('https://gql.hashnode.com', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query: POSTS_QUERY, variables }),
});

When I added a new post, my local dev server still only showed the old posts.

The Failed Attempts

Hashnode uses Stellate, a powerful GraphQL Edge CDN. Stellate sits between your frontend and Hashnode's database, caching responses to make the API blazing fast. However, its caching mechanism is exceptionally aggressive.

Here are the standard tricks I tried to bypass the cache, all of which failed:

1. Setting standard HTTP headers: Adding Cache-Control: no-cache and Pragma: no-cache to the fetch call. Stellate ignores these from the client.

2. URL Query Params: Appending a timestamp ?_t=${Date.now()} to the endpoint URL. Since this is a POST request, Stellate keys the cache off the request body, not just the URL.

3. GraphQL extensions: Adding extensions: { cacheKey: Date.now() } to the JSON body. Stellate normalization strips this out.

4. Unknown GraphQL Variables: Injecting _cacheBust: Date.now() into the variables object. Stellate strips unknown variables.

5. GraphQL Comments: Injecting # ${Date.now()} directly into the query string. Stellate parses and normalizes the query string, stripping comments before hashing the cache key.

No matter what I did, inspecting the network tab always revealed the same mocking response header: gcdn-cache: HIT.

The Real Issue: Stellate Needs the id Field

The root cause isn't that Stellate is ignoring your cache-busting hacks; it's that Stellate doesn't know the data is stale.

Stellate automatically invalidates its cache when backend data changes (mutations). But to do this effectively across complex GraphQL graphs, it relies on a core concept: tracking Node IDs.

If your query doesn't ask for the id of the entities it's fetching, Stellate cannot trace the cached data back to the actual database records. When Hashnode updates its database, Stellate's purge mechanism fires, but if your cached query didn't include IDs, Stellate doesn't know to invalidate that specific query.

This is a well-known issue internally at Hashnode — they even created an ESLint plugin (require-id-when-available) for their own engineers to prevent it!

The Solution

The fix is almost disappointingly simple. You must include the id field in all your GraphQL queries and fragments related to Hashnode.

My original query looked like this:

query Publication(\(host: String!, \)first: Int!) {
  publication(host: $host) {
    posts(first: $first) {
      edges {
        node {
          slug
          title
          brief
          publishedAt
        }
      }
    }
  }
}

The fix is simply adding id inside the node:

query Publication(\(host: String!, \)first: Int!) {
  publication(host: $host) {
    id  # <-- ESSENTIAL FOR LIST INVALIDATION
    posts(first: $first) {
      edges {
        node {
          id  # <-- ESSENTIAL FOR ENTITY INVALIDATION
          slug
          title
          brief
          publishedAt
        }
      }
    }
  }
}

Make sure to add id to everywhere you query entities: the parent publication object, posts, post, seriesList, etc.

Why both?

• Adding id to the node tells Stellate to update the cache for that specific post if it gets edited.

• Adding id to the parent publication tells Stellate to invalidate the entire list of posts for that publication when a new post is published or deleted.

Once I updated my queries and refreshed, the CDN properly registered the unique records and lists. New posts now invalidate the cache automatically, and the API returns fresh data immediately upon publishing.

Takeaway: When working with GraphQL APIs behind Edge CDNs like Stellate, always fetch the id. It's not just good practice; it's the anchor for their entire caching strategy.

But if you are building a Single Page Application (SPA) with React, Vite, and React Router, this out-of-the-box behavior breaks down.

In a React SPA, clicking a link doesn't trigger a page reload. React simply unmounts the old component and mounts the new one while manipulating the browser's URL history. Because the page never actually "reloads," Google Analytics never registers the new URL, and your analytics will show users seemingly stuck on the homepage forever.

Here is exactly how I solved this for my portfolio site.

1. The Environment Setup

First, avoid hardcoding your tracking ID into your source code. If your repo is public, anyone could scrape it. Add your Measurement ID (found in your GA dashboard, usually starting with G-XXXXXXXXXX) to your .env file.

VITE_GA_TRACKING_ID=G-**********

2. The Initial HTML Snippet (Modified)

You still need the base Google Analytics tracking code in your index.html.

However, we need to make one critical modification: we must tell GA4 not to automatically track the initial page view. If we don't disable it, we will end up double-counting the first page load when our React Router listener kicks in later.

In index.html:

  <!-- Google tag (gtag.js) -->
  <script async src="https://www.googletagmanager.com/gtag/js?id=%VITE_GA_TRACKING_ID%"></script>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag() { dataLayer.push(arguments); }
    gtag('js', new Date());

    // IMPORTANT: Disable the default page_view tracking here!
    gtag('config', '%VITE_GA_TRACKING_ID%', { send_page_view: false });
  </script>

Note on Vite: I used %VITE_GA_TRACKING_ID% to inject the environment variable directly into the HTML at build time.

3. Creating the Route Listener Component

Now we need a way to listen to URL changes inside React and ping Google Analytics manually. We can create a lightweight, invisible component to handle this using the useLocation hook from react-router-dom.

Create components/Analytics.tsx:

import { useEffect } from 'react';
import { useLocation } from 'react-router-dom';

// Extend window object for TypeScript so it doesn't complain about window.gtag
declare global {
  interface Window {
    gtag: (...args: any[]) => void;
  }
}

export const Analytics = () => {
  const location = useLocation();

  useEffect(() => {
    // Read the tracking ID from environment variables
    const GA_MEASUREMENT_ID = import.meta.env.VITE_GA_TRACKING_ID;

    // Ensure the ID exists and the gtag function was loaded successfully
    if (GA_MEASUREMENT_ID && typeof window.gtag === 'function') {

      // Ping Google Analytics manually
      window.gtag('config', GA_MEASUREMENT_ID, {
        page_path: location.pathname + location.search,
      });

    }
  }, [location]); // Re-run this effect every time the URL changes

  return null; // This component is invisible
};

4. Wiring it up to the Router

Finally, we need to mount our new <Analytics /> component.

The most important rule here is that Analytics must be placed inside the <BrowserRouter> but outside of the <Routes> block. If it's outside the Router, the useLocation hook will throw a contextual error.

In index.tsx:

import { Analytics } from './components/Analytics';
// ... other imports

const App = () => {
  return (
    <HelmetProvider>
      <BrowserRouter>

        {/* Place the listener here! */}
        <Analytics />
        <ScrollToTop />

        <Suspense fallback={<LoadingFallback />}>
          <Routes>
            <Route path="/" element={<HomePage />} />
            <Route path="/about" element={<AboutPage />} />
            {/* ... other routes */}
          </Routes>
        </Suspense>

      </BrowserRouter>
    </HelmetProvider>
  );
};

The Result

And that's it!

Now, when a user lands on vicentereyes.org, the Google Analytics script loads. Then, React boots up, mounts the router, hits the <Analytics /> component, and fires a page view event for /.

When the user clicks "Projects", React Router handles the transition, the URL updates to /projects, the useEffect inside <Analytics /> fires again, and a clean page view event for /projects is pushed to Google. Perfect SPA tracking, no heavy external libraries required.

Here is a breakdown of the key architectural, functional, and design enhancements made during this update cycle.

1. Revamping the Projects Showcase

The core of any developer's portfolio is their past work. The goal was to transition from a simple showcase to a comprehensive case-study format.

• Dedicated Project Pages: We moved away from just listing projects and introduced a dedicated /projects route for browsing, alongside dynamic /projects/:slug pages for deep-dive case studies.

• Rich Storytelling & Metadata: The underlying data structure (constants.ts) was significantly expanded. Instead of just a title and a link, projects now feature detailed Challenge, Solution, and Result sections. This allows visitors to understand not just what was built, but why and how.

• A Comprehensive Roster: We conducted a thorough audit of the project list. We restored several missing projects (such as Fashion Boulevard, Renegade Jewelry, and Limitless Fashion) and meticulously refined the copywriting for over 20 individual projects. Every entry now accurately reflects the specific technologies used, the unique challenges faced, and the tangible business results achieved.

• Status Badges: Projects were clearly categorized with 'Active' (live links) or 'Sunset' statuses, providing immediate context to the visitor.

2. A Dedicated, Highly Functional Contact Experience

To facilitate better communication with potential clients and collaborators, the contact flow needed to be both visually striking and technically robust.

• The Neo-Brutalist /contact Page: A brand new, standalone contact page was built from the ground up, strictly adhering to the site's bold, high-contrast Neo-Brutalist design language.

• Seamless EmailJS Integration: The form was wired up using EmailJS. We enhanced the payload structure so that when a message is sent, the sender's Name and Email are clearly prepended to the email body, ensuring essential context is never lost in the inbox.

• Engaging UX States: We replaced default browser behaviors with custom, visually engaging UI states. Upon a successful submission, the form gracefully disappears, replaced by a bold "Message Received!" confirmation screen. Similarly, clear error banners were implemented to guide the user if something goes wrong.

• Flawless Dark Mode: Careful attention was paid to color inheritance, ensuring the form inputs and labels remain highly legible and aesthetically pleasing when a user toggles Dark Mode.

3. Globalizing "Icen's AI Twin"

The custom AI Assistant is a standout feature of the site, but its utility was previously limited to the homepage.

• Ubiquitous Access: We refactored the application's routing structure (index.tsx), elevating the <AIAssistant /> component to the top-level layout.

• Always Ready to Help: Now, the AI chat bubble floats seamlessly across all routes—whether a visitor is browsing a specific project case study, reading the About page, or looking at Services. "Icen's AI Twin" is now a persistent, helpful presence throughout the entire user journey.

4. Polishing the Details

Great design is in the details, and several smaller tweaks were made to ensure a cohesive experience:

• Button Consistency: We added new variants (like a dedicated 'white' variant) to the core <Button /> component to ensure calls-to-action—like the "Next Project" button—look perfect regardless of whether the site is in light or dark mode.

• Routing Refinements: Main navigation links and homepage CTAs were updated to integrate smoothly with the new dedicated routes, eliminating reliance on simple anchor hashes where full pages now exist.

The Result

These focused updates transform the portfolio from a simple directory into an interactive, narrative-driven platform. It not only showcases technical capability through the projects themselves but also through the polished, performant, and highly detailed execution of the portfolio site itself.

Is it a performance-boosting revolution or a maintenance nightmare? Let’s break down the pros and cons of moving from a native WordPress site to a headless architecture.

What Exactly is "Headless" WordPress?

In a Native (Monolithic) setup, WordPress is the whole engine and the car body. It handles the database, the admin dashboard, and the "head"—the theme that your visitors see.

In a Headless (Decoupled) setup, we chop off the head. WordPress stays in the garage as a backend content management system (CMS). It serves your posts and pages as raw data through an API (REST or WPGraphQL). Your "head" is a completely separate application built with modern tools like Next.js, React, or Vue.

The Pros: Why Go Headless?

1. Performance and Core Web Vitals

Native WordPress themes can become "bloated" with CSS and JavaScript from dozens of plugins. Headless sites typically use Static Site Generation (SSG). Your pages are pre-rendered into lightweight HTML files and served via a Global CDN.

• The Result: Instant load times and perfect 100/100 Lighthouse scores.

2. Future-Proofing with "Omnichannel" Content

When your content is just an API endpoint, it isn't trapped on a website. You can pull that same "About Us" text into:

• An iOS or Android mobile app.

• A smart watch interface.

• Digital signage or kiosks.

3. Fortified Security

Standard WordPress sites are frequent targets for bots. By separating the frontend, you can hide your wp-admin on a private subdirectory or a different server entirely. Hackers can't "brute force" a login page they can't even find.

4. Developer Happiness

Modern developers often prefer working with React or TypeScript over legacy PHP templates. Decoupling allows your team to use the best tools for the job without being restricted by the WordPress "Loop."

The Cons: The Hidden Costs of Freedom

1. The "Preview" Problem

In native WordPress, you hit "Preview" and see your changes instantly. In headless, the WordPress dashboard doesn't know what your separate frontend looks like. Setting up a live preview requires custom engineering and additional infrastructure.

2. Plugin Compatibility Issues

This is the biggest hurdle. Many popular plugins (like Gravity Forms, Yoast SEO, or Elementor) rely on the native theme layer to function. In a headless setup, these won't work out of the box. You'll need to manually fetch that data via the API and rebuild the UI from scratch.

3. Increased Complexity & Hosting Costs

You are no longer managing one site; you are managing two separate environments:

1. The Backend: WordPress hosting (e.g., WP Engine, Kinsta).

2. The Frontend: JavaScript hosting (e.g., Vercel, Netlify).

4. SEO Responsibility

While headless is faster (which helps SEO), you lose the "automatic" benefits of SEO plugins. You must manually handle your meta tags, sitemaps, and schema markup within your JavaScript framework.

The Verdict: Should You Make the Switch?

Final Thought

Moving to headless isn't just a technical upgrade; it’s a change in philosophy. It’s perfect for enterprise-grade projects that need to scale, but for a standard business site, the simplicity of a well-optimized native WordPress theme is often still the smarter play.

If you are hitting the "glass ceiling" of Liquid or simply want to know if the investment is worth the ROI, here is the breakdown.

🚀 The Pros: Why Brands Go Headless

1. Unrestricted UX & Performance

In a traditional Liquid setup, you are bound by Shopify’s theme engine and fixed URL structures. Headless breaks those walls.

• Near-Instant Speeds: By leveraging SSR (Server-Side Rendering) or SSG (Static Site Generation), you can achieve perfect Lighthouse scores and instantaneous page transitions.

• Complex Interactions: If your brand requires high-state interfaces—like advanced product configurators or immersive 3D/AR experiences—React-based frameworks handle these much more gracefully than synchronous Liquid rendering.

2. SEO & URL Flexibility

This is often the "deciding factor" for large migrations. Native Shopify uses a fixed /products/ and /collections/ structure. If you need custom URL patterns to maintain legacy SEO rankings or specific site hierarchies, headless is currently the only way to achieve that level of control.

3. "Best-of-Breed" Tech Stack

Headless allows you to decouple your content from your commerce. You can pull high-end editorial content from a CMS like Sanity or Contentful and merge it seamlessly with Shopify’s checkout and product data.

⚠️ The Cons: The Hidden Costs of Freedom

1. The "App" Integration Gap

This is the biggest hurdle for most merchants. In Liquid, most Shopify apps "just work" via theme app extensions. In a headless setup, apps do not work out of the box. You must manually integrate every service (reviews, loyalty, search) via its API, which significantly increases development time and budget.

2. Increased Maintenance & Complexity

When you go headless, you are no longer just managing a store; you are managing a software application.

• Infrastructure: You (or your dev team) are responsible for the frontend hosting (Vercel, Netlify, or Shopify Oxygen).

• Developer Dependency: Even small frontend tweaks usually require a developer. You lose the "drag-and-drop" agility of the Shopify Theme Editor unless you invest heavily in building a custom preview system.

3. Higher Initial Investment

A custom Liquid theme might take weeks to build, whereas a headless build typically takes months. The initial CAPEX is significantly higher due to the custom engineering required to replicate basic Shopify features.

Quick Comparison: Liquid vs. Headless

The Verdict: Is it right for you?

Headless is a powerful tool, but it’s a business decision, not just a technical one. I usually recommend it only if:

1. Scale: You are a high-volume merchant where a 500ms speed improvement translates to significant revenue.

2. Specific Utility: You require a complex UI that is impossible to build within Liquid constraints.

3. Resources: You have a dedicated engineering team or an agency retainer to manage the ongoing technical debt.

For many, a well-optimized Liquid theme remains the most agile and cost-effective way to scale. But for those ready to push the boundaries of e-commerce, headless is the frontier.

Are you considering making the switch?
I’d love to hear your thoughts in the comments or help you audit your current tech stack to see which path fits your 2026 growth goals.

Today, we're solving a classic mathematical problem: Checking if a Number is Prime.

The Problem

The goal is to write a function that determines whether a given number is prime.

• A prime number is a natural number greater than 1 that has no positive divisors other than 1 and itself.

• The function should return True if the number is prime, and False otherwise.

Examples:

• is_prime(7) → Should return True (7 is only divisible by 1 and 7)

• is_prime(10) → Should return False (10 is divisible by 1, 2, 5, and 10)

• is_prime(2) → Should return True (2 is the only even prime number)

The Solution

Here is the Python implementation:

def is_prime(n):
    """
    Checks if a number is prime.
    """
    # Numbers ≤ 1 are not prime by definition
    if n <= 1:
        return False

    # 2 is the only even prime number
    if n == 2:
        return True

    # Check if n is even (and not 2)
    if n % 2 == 0:
        return False

    # Check odd divisors from 3 up to the square root of n
    for i in range(3, int(n**0.5) + 1, 2):
        if n % i == 0:
            return False

    return True

# Test cases
print(is_prime(7))   # True
print(is_prime(10))  # False
print(is_prime(2))   # True

Code Breakdown

Let's walk through the code line by line:

1. def is_prime(n):

   • Defines a function named is_prime that takes an integer n as input.

2. if n <= 1:

   • Checks if the number is less than or equal to 1.

   • By mathematical definition, numbers ≤ 1 are not considered prime, so we return False.

3. if n == 2:

   • Special case: 2 is the only even prime number.

   • If n is 2, we immediately return True.

4. if n % 2 == 0:

   • Checks if n is even (divisible by 2).

   • Since we've already handled the case where n == 2, any other even number is not prime.

   • Returns False for all even numbers greater than 2.

5. for i in range(3, int(n**0.5) + 1, 2):

   • This is the optimization key! We only need to check divisors up to the square root of n.

   • Why? If n has a divisor greater than √n, it must also have a corresponding divisor smaller than √n.

   • n**0.5 calculates the square root of n.

   • int(...) converts it to an integer.

   • + 1 ensures we include the square root itself in the range (since range is exclusive of the end value).

   • 2 as the step means we only check odd numbers (3, 5, 7, 9, ...), skipping all even numbers since we already know they're not prime.

6. if n % i == 0:

   • Checks if n is divisible by the current value of i.

   • If it is, n has a divisor other than 1 and itself, so it's not prime.

   • Returns False immediately.

7. return True

   • If we've checked all possible divisors and found none, the number is prime.

   • Returns True.

Example Walkthrough

Let's trace the function with is_prime(29):

1. Check: 29 <= 1? No, continue.

2. Check: 29 == 2? No, continue.

3. Check: 29 % 2 == 0? No (29 is odd), continue.

4. Loop: Check divisors from 3 to √29 ≈ 5.38, so we check 3 and 5.

   • i = 3: 29 % 3 == 0? No (29 ÷ 3 = 9 remainder 2)

   • i = 5: 29 % 5 == 0? No (29 ÷ 5 = 5 remainder 4)

5. Result: No divisors found, return True. ✅

Now let's trace is_prime(15):

1. Check: 15 <= 1? No, continue.

2. Check: 15 == 2? No, continue.

3. Check: 15 % 2 == 0? No (15 is odd), continue.

4. Loop: Check divisors from 3 to √15 ≈ 3.87, so we check 3.

   • i = 3: 15 % 3 == 0? Yes! (15 ÷ 3 = 5)

5. Result: Divisor found, return False. ❌

Key Optimizations

This implementation uses several clever optimizations:

• Early Returns: We return False as soon as we find any divisor, avoiding unnecessary checks.

• Reduced Search Space: Only checking up to √n dramatically reduces the number of iterations.

• Skip Even Numbers: After handling 2, we skip all other even numbers by stepping by 2 in our loop.

These optimizations make the function efficient even for larger numbers! 🚀

Happy coding! 💻

This week, we executed a comprehensive technical overhaul of the Oatopia Shopify theme. Our focus shifted from foundational modernization of legacy assets to high-level performance tuning and UX polishing.

⚡ Performance & Core Web Vitals

Speed is a feature. We spent significant time reducing page weight and optimizing how the browser handles our most important assets.

• Image Modernization: Conducted a project-wide audit to replace legacy filters (img_url, file_img_url, asset_img_url) with the modern image_url standard.

• Next-Gen Delivery: Enabled automatic WebP/AVIF delivery via Shopify CDN and implemented loading="lazy" for off-screen images.

• LCP Optimization: Updated the collection banner to use fetchpriority="high", signaling the browser to prioritize the hero image immediately.

• HTML Bloat Reduction: Refactored the QuickBuy feature to use a minimal manual JSON object instead of injecting massive data for every product card, drastically reducing page weight.

• Asset Loading: Moved global.bundle.js to the end of the body to unblock rendering and implemented a "print" media trick for non-blocking Adobe Typekit fonts.

🗺️ Navigation & Header Architecture

We addressed several layout shifts and usability hurdles within the site's navigation.

• Smart Hover Logic: Added a 150ms grace period to dropdowns and implemented auto-close logic for adjacent menus to prevent overlapping during mouse sweeps.

• Desktop-to-Mobile Parity: Fixed an issue where secondary links like "Account" were missing from the mobile drawer by updating snippets/sidebar-nav.liquid.

• Mega Menu Styling: Updated the layout to support a 3-column categorical structure (e.g., Shop > Oat Bakes, Flapjacks, Giftboxes).

• Flexibility: Removed hardcoded CSS constraints to restore dynamic logo sizing based on theme settings.

🖌️ UI/UX & Visual Consistency

Refining the "feel" of the store to match the Oatopia brand identity.

• Grid Stability: Optimized product grids to ensure rows are fully filled (no empty slots).

• Mobile "Gap" Fix: Forced mobile 2-column grids to always be divisible by 2 to prevent "hanging" items at the end of a page.

• Interactive Polish: Added a "Zoom + Bold" effect for dropdown items and increased horizontal padding on "View All" buttons for better prominence.

• Brand Styling: Customized the footer "Subscribe" button with a Blueberry background and Demarara text.

• Layout Fixes: Applied flex-nowrap to the header to prevent the Search and Cart icons from "squishing" on smaller desktop screens.

🛠️ Technical Fixes & SEO

Behind-the-scenes improvements for long-term site health.

• Scroll Locking: Implemented JavaScript handlers for full body-scroll locking when menus are open to prevent secondary page scrolling.

• SEO Hardening: Applied rel="nofollow" to all raw image thumbnail links to prioritize high-value page indexing.

• Enhanced Product Blocks: Updated the product template schema to support multiple independent, per-product FAQ/Collapsible blocks.

• Alpine.js Integration: Enhanced the menu state management using Alpine.js to handle hover delays and click-outside events effectively.

🏁 Conclusion

By the end of this sprint, all core modernization, performance optimization, and layout stabilization tasks have been completed and verified on the development theme. The site now boasts a significantly more robust navigation system and a leaner code architecture, particularly regarding image handling and HTML delivery

Today, we're tackling a popular interview question: Group Anagrams.

The Problem

The goal is to write a function that groups words that are anagrams of each other from a given list of strings.

• An anagram is a word or phrase formed by rearranging the letters of a different word or phrase, typically using all the original letters exactly once.

• The function should return a list of lists, where each sublist contains words that are anagrams.

Example:

• group_anagrams(['listen', 'silent', 'hello', 'world', 'enlist'])

  • Should return: [['listen', 'silent', 'enlist'], ['hello'], ['world']]

The Solution

Here is the Python implementation:

def group_anagrams(words):
    """
    Groups words that are anagrams of each other.
    """
    # Handle edge case: if input is None or empty list
    if words is None or len(words) == 0:
        return []

    anagram_groups = {}

    for word in words:
        # Create a key that is the same for all anagrams
        # 1. Lowercase to ensure case-insensitivity
        # 2. Sort the characters
        # 3. Convert to tuple to make it hashable (usable as a dict key)
        key = tuple(sorted(word.lower()))

        if key in anagram_groups:
            anagram_groups[key].append(word)
        else:
            anagram_groups[key] = [word]

    return list(anagram_groups.values())

# Test cases
print(group_anagrams(['listen', 'silent', 'hello', 'world', 'enlist']))
# Output: [['listen', 'silent', 'enlist'], ['hello'], ['world']]

Code Breakdown

Let's walk through the code line by line:

1. def group_anagrams(words):

   • Defines a function named group_anagrams that takes a list of strings words as input.

2. if words is None or len(words) == 0:

   • Checks if the input list is None or empty. If so, it returns an empty list []. This handles edge cases effectively.

3. anagram_groups = {}

   • Initializes an empty dictionary called anagram_groups.

   • Key: A sorted tuple of characters (unique signature for anagrams).

   • Value: A list of words that match that signature.

4. for word in words:

   • Iterates through each word in the input list.

5. key = tuple(sorted(word.lower()))

   • word.lower(): Converts the word to lowercase so 'Listen' and 'listen' are treated the same.

   • sorted(...): Sorts the characters alphabetically. For example, 'listen' becomes ['e', 'i', 'l', 'n', 's', 't'].

   • tuple(...): Converts the sorted list into a tuple. This is crucial because lists are mutable and cannot be used as dictionary keys, but tuples are immutable and hashable.

6. if key in anagram_groups:

   • Checks if this sorted character tuple (the key) is already in our dictionary.

7. anagram_groups[key].append(word)

   • If the key exists, it means we've found another anagram for this group. We append the original word to the list associated with this key.

8. else: anagram_groups[key] = [word]

   • If the key does not exist, this is the first word of this anagram type we've encountered. We create a new entry in the dictionary with the key and a new list containing the current word.

9. return list(anagram_groups.values())

   • anagram_groups.values() retrieves all the lists of anagrams from the dictionary.

   • list(...) converts this view object into a standard list and returns it.

Example Walkthrough

Let's trace the function with ['listen', 'silent', 'hello']:

1. Initialization: anagram_groups = {}

2. Word 1: 'listen'

   • key: ('e', 'i', 'l', 'n', 's', 't')

   • Key not in map. Add it: anagram_groups = {('e', 'i', 'l', 'n', 's', 't'): ['listen']}

3. Word 2: 'silent'

   • key: ('e', 'i', 'l', 'n', 's', 't') (Same as 'listen'!)

   • Key exists. Append: anagram_groups = {('e', 'i', 'l', 'n', 's', 't'): ['listen', 'silent']}

4. Word 3: 'hello'

   • key: ('e', 'h', 'l', 'l', 'o')

   • Key not in map. Add it.

Final Result: list(anagram_groups.values()) -> [['listen', 'silent'], ['hello']]

Happy coding! 💻

Enter fetchpriority. This HTML attribute is a game-changer for telling browsers exactly which assets deserve the "VIP treatment."

What is fetchpriority?

The fetchpriority attribute is a browser hint that signals the relative importance of a resource. While browsers are generally smart at guessing what to load first, they aren't psychic. They might prioritize a late-discovery script over the massive hero image that is actually the most important thing on the screen.

By adding fetchpriority="high", you’re moving that asset to the front of the line.

How it Works

When a browser parses a page, it assigns a priority level (Low, Medium, High, or Very High) to every resource.

• Images are usually "Low" or "Medium" by default.

• Scripts and CSS are usually "High."

By manually setting the priority, you override these defaults to ensure your "hero" elements don't get stuck behind less critical background tasks.

Why Use It? (The LCP Connection)

Largest Contentful Paint (LCP) measures when the largest image or text block becomes visible. If your hero image is the LCP element, fetchpriority="high" can:

1. Reduce Queueing Time: The browser starts downloading the image sooner.

2. Optimize Bandwidth: It allocates more "pipe" to that specific asset.

3. Improve UX: Users see the "meat" of your page faster, reducing bounce rates.

Note: Real-world tests have shown that correctly implementing fetchpriority can improve LCP by 20-30% in many cases.

How to Implement It

You can apply this attribute to <img>, <link>, <script>, and even <iframe> tags.

1. For Hero Images

This is the most common use case. If you have an image above the fold, give it the high-priority tag.

HTML

<img src="hero-banner.jpg" fetchpriority="high" alt="New Summer Collection">

2. For Preloaded Resources

If you are preloading a critical asset in the <head>, you can specify the priority there as well.

HTML

<link rel="preload" href="main-style.css" as="style" fetchpriority="high">

3. Deprioritizing Non-Critical Assets

Conversely, you can use fetchpriority="low" for things that don't matter immediately, like images further down the page (below the fold) or a non-essential tracking script.

Best Practices to Keep in Mind

• Don't Overdo It: If everything is "high" priority, nothing is. Only use it for the 1 or 2 most critical elements on the screen.

• Combine with loading="lazy": Use fetchpriority="high" for the top of the page and loading="lazy" for everything else. Never use both on the same image.

• Test with DevTools: You can see the "Priority" column in the Network Tab of Chrome DevTools to verify if your hint is working.

Conclusion

fetchpriority="high" is one of the simplest yet most effective tools in a developer's performance toolkit. It’s not a magic wand, but it’s a very loud megaphone that helps the browser focus on what truly matters to your users.