DEV Community: Alex Chen

How I Fixed Bugs in 30+ Open Source Projects (And What I Learned)

Alex Chen — Sat, 13 Jun 2026 03:46:29 +0000

How I Fixed Bugs in 30+ Open Source Projects (And What I Learned)

Over the past few months, I've been contributing to open source as an independent developer. No big company backing, no team — just me, a laptop, and a lot of caffeine. Along the way, I've submitted pull requests to 30+ repositories across the Python, JavaScript, TypeScript, and Rust ecosystems.

Here's what I learned from the process — the good, the bad, and the "I wish someone told me this earlier."

Why Contribute to Open Source?

Let's get the obvious out of the way: it's not about the money (at least not directly). Most bounties pay $50-$500, and you'll spend 10-20 hours on a single PR if it involves deep codebase exploration.

The real value is:

Reputation — Each merged PR is a public signal that you can read, understand, and improve other people's code
Learning — You'll see how major projects are structured, tested, and maintained
Network — Maintainers remember helpful contributors. Jobs come from these relationships
Scratching your own itch — Fix a bug that annoys you? Everyone benefits

My Process: Finding Good Issues

Step 1: Pick the Right Projects

Not all projects are equally welcoming to new contributors. Here's my filter:

Signal	Good ✅	Bad ❌
Response time	< 7 days	> 30 days or never
Issue labels	`good first issue`, `help wanted`	None
CI/CD	Green, fast builds	Broken, 30min+ builds
PR merge rate	> 60% of open PRs merge	< 20% merge

Step 2: Find Issues You Can Actually Fix

I look for:

Bug reports with clear reproduction steps — Someone already did the hard work of identifying what's wrong
Issues labeled easy-fix or similar — The maintainer thinks it's approachable
Issues in domains I know — Don't pick a C++ compiler bug if you've never written C++

Step 3: Before Writing Code

This is where most beginners fail. Don't start coding yet!

Read the CONTRIBUTING.md — Every project has different style, commit message format, and PR requirements
Look at recent merged PRs — What do good PRs in this project look like?
Comment on the issue first — Say "I'm working on this" so others don't duplicate effort
Set up the dev environment — Make sure tests pass before you change anything

Real Examples from My Contributions

Example 1: One-Line Fix (Pygments)

In pygments/pygments#3127, the CUDA lexer was inheriting from the C lexer instead of the C++ lexer. Since nvcc is a C++ compiler, modern CUDA code uses C++ features like constexpr and class.

The fix: One line change

# Before
class CudaLexer(CLexer):
# After  
class CudaLexer(CppLexer):

Sometimes the smallest fixes have the biggest impact.

Example 2: TLS Socket Leak (Tornado)

tornadoweb/tornado#3614 was trickier. When a TLS handshake times out in TCPClient.connect(), the underlying socket was leaking because ownership transferred to a new SSLIOStream that was then discarded on timeout.

The fix required:

Understanding Tornado's stream ownership model
Adding proper cleanup in the error path
Writing a test that reproduces the race condition

Total time: ~3 hours. Lines changed: ~15. But the learning about async socket handling was invaluable.

What Goes Wrong (And How to Handle It)

1. Your PR Gets Ignored 😴

This happens. A lot. Some maintainers are overwhelmed, some projects are understaffed, sometimes your PR just gets lost in the shuffle.

What to do:

Wait 2 weeks before pinging
When you ping, add value: "I noticed X merged recently, wondering if there's anything else needed for this one"
If another month passes, it might be time to move on

2. Your PR Gets Rejected 🙅

Don't take it personally. Code review is about the code, not about you.

Common reasons:

Missing tests — Always include tests when possible
Style mismatch — Read the project's style guide
Scope creep — Keep PRs focused on one thing
Performance concerns — Your "fix" might be slower than the original!

3. You Get Blocked From a Project 🚫

Yes, this happened to me. Some projects have aggressive anti-spam filters, and submitting multiple PRs quickly can trigger them.

What to do:

Don't panic
Move on to other projects — there are millions of repos
Maybe reach out to maintainers via other channels (Discord, email) to understand why

Tools That Helped Me

GitHub CLI (gh) — Essential for everything: creating PRs, checking statuses, managing forks
git-worktree — Work on multiple issues simultaneously without stashing
pytest / jest / go test — Whatever the project uses, master it
IDE with good git integration — I use VS Code with GitLens

By The Numbers (So Far)

Metric	Value
PRs submitted	30+
Repos contributed to	15+
Merged (so far)	Still waiting on most...
Average wait time for review	2-8 weeks
Biggest lesson	Patience matters more than code quality

What's Next?

I'm continuing to contribute to projects I use daily. The goal isn't to hit some number — it's to become the kind of developer who can jump into any codebase and make meaningful improvements.

If you're thinking about contributing but haven't started: open an issue right now. Find a project you use, look at their issue tracker, and pick something small. Your future self will thank you.

Have you contributed to open source? What's your experience been? Let me know in the comments!

Linux Command Line: The 50 Commands Every Developer Needs (2026)

Alex Chen — Fri, 12 Jun 2026 16:39:21 +0000

Linux Command Line: The 50 Commands Every Developer Needs (2026)

You don't need to memorize thousands of commands. These 50 cover 95% of what you'll do daily as a developer.

File & Directory Operations

# Navigation
pwd                          # Where am I?
cd ~/projects                 # Go to directory
cd -                          # Go to previous directory
ls -lah                      # List files (long, human-readable, hidden)

# Finding things
find . -name "*.js"          # Find by name (recursive)
find . -type f -mtime -7     # Files modified in last 7 days
grep -r "TODO" ./src         # Search file contents recursively
rg "function" ./src          # Ripgrep — faster alternative

# File operations
cp file.txt backup.txt       # Copy
cp -r folder/ backup/        # Copy directory
mv old.txt new.txt           # Move/rename
rm file.txt                  # Delete (gone forever!)
rm -rf folder/               # Delete directory + contents
mkdir -p a/b/c/d             # Create nested directories
touch newfile.js             # Create empty file
ln -s /path/to/file link     # Create symbolic link

# Viewing files
cat file.txt                 # Show entire file
less file.txt                # Scroll through (q to quit)
head -20 file.txt            # First 20 lines
tail -f logfile.log          # Last lines + follow live updates!
wc -l file.txt               # Count lines
du -sh *                      # Disk usage per item (human-readable)

Text Processing

# Search within files
grep "error" app.log         # Find matching lines
grep -n "error" app.log      # With line numbers
grep -C 3 "error" app.log    # Show 3 lines before/after match
grep -r "import" src/        # Recursive search in directory

# Find and replace
sed 's/old/new/g' file.txt   # Replace all occurrences
sed -i.bak 's/foo/bar/g' *  # In-place replace with backup

# Stream editing with awk
awk '{print $1, $3}' data.txt # Print columns 1 and 3
awk '/error/{count++} END {print count}' log.txt # Count matches

# Sort & unique
sort names.txt               # Alphabetical sort
sort -rn numbers.txt         # Reverse numeric sort
sort file.txt | uniq -c      # Count occurrences

Process Management

# What's running?
ps aux                       # All processes
top / htop                   # Interactive viewers (q to quit)
pgrep node                   # Find PIDs of node processes

# Controlling processes
kill PID                     # Graceful stop (SIGTERM)
kill -9 PID                 # Force kill (SIGKILL) — last resort
pkill -f "node server"      # Kill by name pattern

# Background jobs
command &                    # Run in background
nohup long-job &             # Survives terminal close
Ctrl+Z                        # Suspend current job
bg                           # Resume suspended job in background
fg                           # Bring to foreground
jobs                         # List background jobs

# Resource monitoring
free -h                      # Memory usage
df -h                        # Disk space
iotop                        # Disk I/O per process
nethogs                      # Network bandwidth per process
vmstat 1                     # System stats every second

Networking

# Connection testing
ping google.com              # Basic connectivity
curl -I https://example.com # HTTP headers only
curl -v https://api.test.com # Verbose request/response

# DNS
dig example.com              # Full DNS info
nslookup example.com         # Simple lookup

# Port checking
ss -tlnp                    # Listening ports + PIDs
nc -zv localhost:3000        # Test if port responds

# SSH essentials
ssh user@host                # Connect to remote
ssh -i key.pem user@host     # Connect with specific key
scp file.txt user@host:/path/ # Copy TO server
scp user@host:/path/file ./   # Copy FROM server
ssh-keygen -t ed25519        # Generate SSH key pair
ssh-copy-id user@host        # Copy public key to server

Permissions & Users

# Permission breakdown: rwx rwx rwx
# Owner | Group | Others
# r=4, w=2, x=1 → 7=rwx, 5=r-x, 6=rw-

chmod 755 script.sh           # Owner=rwx, Group+Others=rx
chmod 600 secret.key          # Only owner can read/write
chown www-data:www-data /var/www/html  # Change owner+group

# Sudo
sudo visudo                  # Edit sudoers safely
# deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

DevOps Essentials

# Package management (Debian/Ubuntu)
sudo apt update && sudo apt upgrade -y
sudo apt install nginx
apt search docker

# Systemd services
systemctl status nginx       # Service status
systemctl start nginx        # Start
systemctl restart nginx       # Restart
systemctl enable nginx        # Start on boot
journalctl -u nginx -f        # Follow logs live

# Docker basics
docker ps                    # Running containers
docker images                # Available images
docker exec -it container sh  # Enter container
docker logs -f container      # Follow logs
docker system prune -a        # Clean up unused resources

# Git quick reference
git status                   # Working tree status
git diff                      # Unstaged changes
git add -A && git commit -m "msg"  # Stage + commit
git push origin main          # Push
git log --oneline -10         # Recent commits compact

Power User Chaining

# Pipe: output of one command = input of next
cat access.log | grep "404" | wc -l          # Count 404 errors
ps aux | grep node | awk '{print $2}' | xargs kill  # Kill all node procs

# Redirect output:
command > out.txt          # Write to file (overwrite)
command >> out.txt         # Append to file
command 2> err.txt         # Write stderr to file
command < input.txt        # Read from file

# Combine tools for real workflows:

# Find largest files:
du -sh * | sort -rh | head -10

# Find and delete old log files:
find /var/log -type f -mtime +30 -name "*.log" -delete

# Monitor real-time errors:
tail -f /var/log/app.log | grep --line-buffered ERROR

# Quick HTTP server from any directory:
python3 -m http.server 8000

# Batch rename (add date prefix):
for f in *.jpg; do mv "$f" "$(date +%Y%m%d)_$f"; done

# Extract any archive (universal extract function):
extract() {
  if [ -f $1 ] ; then
    case $1 in
      *.tar.bz2)  tar xjf $1 ;;
      *.tar.gz)   tar xzf $1 ;;
      *.bz2)      bunzip2 $1 ;;
      *.rar)      unrar x $1 ;;
      *.gz)       gunzip $1 ;;
      *.tar)      tar xf $1 ;;
      *.tbz2)     tar xjf $1 ;;
      *.tgz)      tar xzf $1 ;;
      *.zip)      unzip $1 ;;
      *.Z)        uncompress $1 ;;
      *)          echo "'$1' cannot be extracted via extract()" ;;
    esac
  else
    echo "'$1' is not a valid file"
  fi
}

Which command here is new to you? What's your favorite CLI trick that wasn't included?

Follow @armorbreak for more practical developer guides.

CSS Animations & Transitions: A Visual Guide (2026)

Alex Chen — Fri, 12 Jun 2026 16:38:18 +0000

CSS Animations & Transitions: A Visual Guide (2026)

CSS animations and transitions are the secret sauce that makes interfaces feel alive. No JavaScript required — pure CSS power.

Transitions: Smooth State Changes

/* The basics: property + duration + timing function */
.button {
  background: #3b82f6;
  color: white;
  padding: 12px 24px;
  border: none;
  border-radius: 8px;

  /* Transition multiple properties */
  transition: background 0.3s ease,
              transform 0.2s ease,
              box-shadow 0.3s ease;
}

/* Hover state — the transition animates TO these values */
.button:hover {
  background: #2563eb;           /* Color change */
  transform: translateY(-2px);   /* Lift effect */
  box-shadow: 0 8px 20px rgba(59,130,246,0.35); /* Shadow grows */
}

/* Timing functions explained:
   linear    → Constant speed (robotic)
   ease      → Slow start, fast middle, slow end (default, natural)
   ease-in   → Slow start (good for entering)
   ease-out  → Slow end (good for leaving)
   ease-in-out → Both (good for full cycles)
   cubic-bezier() → Custom curve for precise control
*/

/* Custom easing for a snappy feel */
.snappy {
  transition: transform 0.15s cubic-bezier(0.34, 1.56, 0.64, 1);
  /* Overshoots slightly then settles — feels "alive" */
}

/* Transition all vs specific properties */
.card { transition: all 0.3s ease; }        // Convenient but less performant
.card { transition: opacity 0.3s, transform 0.3s; } // Better: specify

/* Delay for staggered effects */
.menu:hover .menu-item:nth-child(1) { transition-delay: 0ms; }
.menu:hover .menu-item:nth-child(2) { transition-delay: 50ms; }
.menu:hover .menu-item:nth-child(3) { transition-delay: 100ms; }
.menu:hover .menu-item { opacity: 1; transform: translateX(0); }

Keyframe Animations: Full Control

/* Define keyframes first */
@keyframes fadeInUp {
  from { 
    opacity: 0; 
    transform: translateY(30px); 
  }
  to { 
    opacity: 1; 
    transform: translateY(0); 
  }
}

@keyframes pulse {
  0%, 100% { transform: scale(1); }
  50%      { transform: scale(1.05); }
}

@keyframes spin {
  from { transform: rotate(0deg); }
  to   { transform: rotate(360deg); }
}

@keyframes slideInFromLeft {
  0%   { transform: translateX(-100%); opacity: 0; }
  100% { transform: translateX(0); opacity: 1; }
}

@keyframes gradientShift {
  0%   { background-position: 0% 50%; }
  50%  { background-position: 100% 50%; }
  100% { background-position: 0% 50%; }
}

@keyframes shimmer {
  0%   { background-position: -200% 0; }
  100% { background-position: 200% 0; }
}

@keyframes typewriter {
  from { width: 0; }
  to   { width: 100%; }
}
@keyframes blink {
  50% { border-color: transparent; }
}

/* Apply animations with animation shorthand */
.hero-title { animation: fadeInUp 0.8s ease-out forwards; }

.loading-spinner {
  width: 40px; height: 40px;
  border: 4px solid #e5e7eb;
  border-top-color: #3b82f6;
  border-radius: 50%;
  animation: spin 1s linear infinite;
}

.notification-badge { animation: pulse 2s ease-in-out infinite; }

.gradient-text {
  background: linear-gradient(90deg, #3b82f6, #8b5cf6, #ec4899);
  background-size: 300% 100%;
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
  animation: gradientShift 3s ease infinite;
}

.typewriter-effect {
  display: inline-block; overflow: hidden; white-space: nowrap;
  border-right: 3px solid #3b82f6;
  animation: typewriter 3s steps(40) 1s forwards,
             blink 0.75s step-end infinite;
}

Practical UI Patterns

/* Loading skeleton (content placeholder while data loads) */
.skeleton {
  background: linear-gradient(
    90deg,
    #f0f0f0 25%,
    #e0e0e0 50%,
    #f0f0f0 75%
  );
  background-size: 200% 100%;
  animation: shimmer 1.5s ease-in-out infinite;
  border-radius: 4px;
}
.skeleton-text { height: 16px; margin-bottom: 8px; }
.skeleton-title { height: 24px; width: 60%; margin-bottom: 16px; }

/* Hover card effect */
.hover-card {
  position: relative;
  transition: transform 0.3s ease, box-shadow 0.3s ease;
}
.hover-card::before {
  content: ''; position: absolute; inset: 0;
  border-radius: inherit;
  background: linear-gradient(135deg, rgba(59,130,246,0.08), rgba(139,92,246,0.08));
  opacity: 0; transition: opacity 0.3s ease;
  z-index: -1;
}
.hover-card:hover {
  transform: translateY(-8px);
  box-shadow: 0 20px 40px rgba(0,0,0,0.12);
}
.hover-card:hover::before { opacity: 1; }

/* Accordion/Collapse animation */
.accordion-content {
  max-height: 0; overflow: hidden;
  transition: max-height 0.4s ease, padding 0.4s ease;
}
.accordion.open .accordion-content {
  max-height: 500px; padding: 16px 0;
}

/* Progress bar animation */
.progress-bar {
  width: 0%; height: 8px;
  background: linear-gradient(90deg, #3b82f6, #8b5cf6);
  border-radius: 4px;
  transition: width 1s cubic-bezier(0.4, 0, 0.2, 1);
}
.progress-bar.indeterminate {
  animation: progressIndeterminate 1.5s ease-in-out infinite;
}
@keyframes progressIndeterminate {
  0% { width: 0%; margin-left: 0%; }
  50% { width: 60%; margin-left: 20%; }
  100% { width: 100%; margin-left: 100%; }
}

/* Ripple click effect */
.ripple-btn { position: relative; overflow: hidden; }
.ripple-btn::after {
  content: ''; position: absolute;
  width: 100%; height: 100%;
  top: 50%; left: 50%;
  transform: translate(-50%, -50%) scale(0);
  border-radius: 50%;
  background: rgba(255,255,255,0.3);
  opacity: 0;
}
.ripple-btn:active::after {
  animation: rippleEffect 0.6s ease-out;
}
@keyframes rippleEffect {
  0% { transform: translate(-50%, -50%) scale(0); opacity: 1; }
  100% { transform: translate(-50%, -50%) scale(4); opacity: 0; }
}

/* Notification badge pop */
.badge-pop {
  animation: badgePopIn 0.3s cubic-bezier(0.175, 0.885, 0.32, 1.275);
}
@keyframes badgePopIn {
  0% { transform: scale(0); opacity: 0; }
  60% { transform: scale(1.2); }
  100% { transform: scale(1); opacity: 1; }
}

Performance Tips

/* Only animate GPU-accelerated properties for 60fps:
✅ transform (translate, rotate, scale)
✅ opacity
❌ width, height, top, left, margin, padding (trigger layout recalculation)
❌ color, background-color (trigger paint)
*/

.gpu-accelerated { will-change: transform, opacity; } /* Hint to browser */
/* But don't overuse! Too many layers = too much memory */

/* Reduce motion for accessibility (IMPORTANT!) */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}
/* Users who set this preference get zero animations — respect it! */

/* Containment hint (helps browser optimize repaint areas) */
.animated-element {
  contain: layout style paint; /* Browser knows this element's changes don't affect siblings */
}

What's your favorite CSS animation trick? What UI pattern would you like to see animated?

Follow @armorbreak for more practical developer guides.

Web Security: OWASP Top 10 — Practical Defense Guide (2026)

Alex Chen — Fri, 12 Jun 2026 16:37:13 +0000

Web Security: OWASP Top 10 — Practical Defense Guide (2026)

Security vulnerabilities follow patterns. The OWASP Top 10 lists the most critical ones — and each has a clear defense strategy.

#1 Broken Access Control

// ❌ Vulnerable: Anyone can access any user's data
app.get('/api/users/:id', (req, res) => {
  const user = await db.users.findById(req.params.id);
  res.json(user); // No ownership check!
});

// ✅ Secure: Enforce resource ownership
app.get('/api/users/:id', authRequired, async (req, res) => {
  if (req.params.id !== req.user.id && req.user.role !== 'admin') {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const user = await db.users.findById(req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });
  res.json({ data: user });
});

// Reusable middleware:
function requireOwnership(getResourceFn) {
  return async (req, res, next) => {
    const resource = await getResourceFn(req.params.id);
    if (!resource) return res.status(404).json({ error: 'Not found' });

    const isOwner = resource.userId?.toString() === req.user?.id;
    const isAdmin = req.user?.role === 'admin';

    if (!isOwner && !isAdmin) {
      return res.status(403).json({ error: 'Access denied' });
    }
    req.resource = resource;
    next();
  };
}
// Usage: app.put('/posts/:id', auth, requireOwnership(findPost), updatePost)

#2 Cryptographic Failures

// ❌ Storing passwords in plain text or weak hash
const hashed = md5(password);        // NEVER!
const hashed = sha1(password);       // NEVER!

// ✅ Use bcrypt/argon2id for passwords
const bcrypt = require('bcrypt');
const SALT_ROUNDS = 12;

async function hashPassword(password) {
  return bcrypt.hash(password, SALT_ROUNDS); // Auto-salts + slow by design
}

async function verifyPassword(inputPassword, storedHash) {
  return bcrypt.compare(inputPassword, storedHash); // Timing-safe comparison
}

// ✅ Encrypt sensitive data at rest (API keys, tokens):
const crypto = require('crypto');

function encrypt(text, keyHex) {
  const iv = crypto.randomBytes(16); // Unique IV per encryption!
  const cipher = crypto.createCipheriv('aes-256-gcm', Buffer.from(keyHex, 'hex'), iv);
  let encrypted = cipher.update(text, 'utf8', 'hex');
  encrypted += cipher.final('hex');
  const authTag = cipher.getAuthTag(); // Integrity verification
  return { encrypted, iv: iv.toString('hex'), authTag: authTag.toString('hex') };
}

function decrypt(encryptedData, keyHex) {
  const decipher = crypto.createDecipheriv(
    'aes-256-gcm', Buffer.from(keyHex, 'hex'),
    Buffer.from(encryptedData.iv, 'hex')
  );
  decipher.setAuthTag(Buffer.from(encryptedData.authTag, 'hex'));
  let decrypted = decipher.update(encryptedData.encrypted, 'hex', 'utf8');
  decrypted += decipher.final('utf8');
  return decrypted;
}

#3 Injection

// SQL Injection:
// ❌ String concatenation (vulnerable to: ' OR 1=1 --)
const query = `SELECT * FROM users WHERE email = '${email}'`;
// ✅ Parameterized queries (always!)
const result = await db.query(
  'SELECT * FROM users WHERE email = $1 AND role = $2',
  [email, role]
);

// NoSQL Injection (MongoDB):
// ❌ Direct object from request body
const user = await db.users.findOne({ username: userInput, password: passInput });
// ✅ Schema validation first, then whitelist fields
const schema = joi.object({
  username: joi.string().alphanum().min(3).max(30),
  password: joi.string().min(12),
});
const { value } = schema.validate({ username: userInput, password: passInput });
const user = await db.users.findOne(value);

// Command Injection:
// ❌ User input in shell command
execSync(`convert ${filename} output.png`);
// ✅ Use library APIs instead of shell commands
const sharp = require('sharp');
await sharp(filename).png().toFile('output.png');

// XSS Prevention:
// In templates: auto-escape by default (EJS <%= %>, React JSX)
// For dynamic HTML:
import DOMPurify from 'dompurify';
const cleanHTML = DOMPurify.sanitize(dirtyHTML, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'br'],
  ALLOWED_ATTR: ['href'],
});

#4 Insecure Design

// ❌ Password reset token in URL (logged everywhere)
app.post('/api/reset-password', async (req, res) => {
  const token = generateToken();
  await sendEmail(email, `Click: https://example.com/reset?token=${token}`);
});

// ✅ Token only used via POST form (not logged in URLs/referrers)
app.post('/api/reset-password', async (req, res) => {
  const token = crypto.randomBytes(32).toString('hex');
  await db.tokens.create({ token, email, expiresAt: Date.now() + 3600000 });
  await sendEmail(email, 'Visit: https://example.com/reset-form');
  // Token submitted via POST form, not URL parameter
});

// ❌ Sequential IDs reveal business data
GET /api/invoices/1001 → /api/invoices/1002 (competitor knows your volume!)

// ✅ Use UUIDs or non-sequential identifiers
const invoiceId = crypto.randomUUID();

#5 Security Misconfiguration

// ❌ Exposing error details to users
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.message, stack: err.stack }); // Leaks internals!
});

// ✅ Generic error messages in production
app.use((err, req, res, next) => {
  const incidentId = crypto.randomUUID();
  logger.error(`[${incidentId}]`, err); // Log full error server-side
  res.status(err.statusCode || 500).json({
    error: process.env.NODE_ENV === 'production' ? 'Internal error' : err.message,
    ...(process.env.NODE_ENV === 'production' && { incidentId }),
  });
});

// ✅ Comprehensive security headers via helmet:
const helmet = require('helmet');
app.use(helmet({
  contentSecurityPolicy: {
    directives: { defaultSrc: ["'self'"], scriptSrc: ["'self'"] },
  },
  hsts: { maxAge: 31536000, includeSubDomains: true },
  noSniff: true,
  frameOptions: { action: 'deny' }, // Prevent clickjacking
}));

// ✅ Rate limiting:
const rateLimit = require('express-rate-limit');
app.use('/api/auth/', rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 10,
  message: { error: 'Too many attempts. Please try again later.' },
}));

#6-10 Quick Reference

#6 Vulnerable & Outdated Components
→ npm audit && npm audit fix (run regularly!)
→ Dependabot / Renovate bot for automated updates

#7 Identification & Authentication Failures
→ Strong password policy (12+ chars, mixed types)
→ Implement account lockout after failed attempts
→ Regenerate session on login (prevent session fixation)
→ Use secure session cookies (httpOnly, sameSite=strict, secure)

#8 Software & Data Integrity Failures
→ Subresource Integrity (SRI) for CDN resources
→ <script src="cdn.js" integrity="sha256-xxx" crossorigin="anonymous">
→ Verify digital signatures for dependencies

#9 Security Logging & Monitoring Failures
→ Log ALL security events: login success/failure, permission denied, rate limit exceeded
→ Include context: IP, userId, timestamp, request ID
→ Set up alerts for anomaly patterns (100 failures in 1 minute from same IP)

#10 Server-Side Request Forgery (SSRF)
→ Never let user-controlled URLs into backend fetch()
→ Validate and sanitize URLs (block internal IPs: 127.x, 10.x, 172.16-31.x, 192.168.x)
→ Use allowlist of permitted domains when possible

Which OWASP vulnerability have you encountered most? What's your security tip?

Follow @armorbreak for more practical developer guides.

Git Advanced: Rebase, Bisect, and the Commands That Save Hours (2026)

Alex Chen — Fri, 12 Jun 2026 16:36:08 +0000

Git Advanced: Rebase, Bisect, and the Commands That Save Hours (2026)

Most developers know git commit and git push. But the real power of Git is in the commands that fix mistakes, untangle history, and save you hours of debugging.

Rebasing: Clean History, Every Time

# The golden rule: NEVER rebase pushed commits (shared history)
# Only rebase local commits that haven't been pushed yet!

# Interactive rebase — your most powerful tool:
git rebase -i HEAD~3    # Rebase last 3 commits
# Opens editor with these options for each commit:
#   pick  abc1234 Commit message 1
#   pick  def5678 Commit message 2
#   pick  ghi9012 Commit message 3

# Available actions:
#   pick (p) = use commit as-is
#   reword (r) = change commit message only
#   edit (e) = pause here to amend files or split commit
#   squash (s) = merge into previous commit (keep message)
#   fixup (f) = merge into previous commit (discard message)
#   drop (d) = remove this commit entirely

# Common rebase workflows:

# Squash last 3 "WIP" commits into one clean commit:
# Change first to "pick", rest to "squash"
# Save → Git opens editor with combined message

# Split a large commit into smaller ones:
git rebase -i HEAD~1
# Change "pick" to "edit" on target commit
# Git pauses at that commit:
git reset HEAD~1          # Unstage all files
git add feature-A.js && git commit -m "Add feature A"
git add feature-B.js && git commit -m "Add feature B"
git add feature-C.js && git commit -m "Add feature C"
git rebase --continue     # Continue rebasing

# Move a commit to a different position:
# In interactive rebase, reorder lines to change commit order!

# Fix a forgotten file in a previous commit:
git rebase -i HEAD~3
# Find the target commit → change to "edit"
# When git pauses: git add forgotten-file && git rebase --continue

# Update branch to match upstream (cleaner than merge):
git fetch origin main
git rebase origin/main    // Replays your commits on top of latest main
// Result: Linear history, no merge commits!

Bisect: Find the Breaking Commit in Minutes

# When did this bug appear? Don't guess — let git tell you!

git bisect start
git bisect bad              # Current version has the bug
git bisect good v2.0.0      # This version was working fine

# Git automatically checks out a middle commit.
# You test it, then:

git bisect good             # This version works → bug was introduced AFTER
git bisect bad              # This version is broken → bug was introduced BEFORE

# Repeat ~5-7 times (binary search halves the search space each time!)
# Git tells you exactly which commit introduced the bug:
# abc1234 is the first bad commit
# commit message: "Refactored auth module"

git bisect reset            # Done — return to original branch

# For automated testing (scriptable bisect):
git bisect start
git bisect bad HEAD
git bisect good v2.0.0
git bisect run npm test      # Runs test command automatically at each step!
# Output: abc1234 is the first bad commit (after N tests)

# Pro tip: Use bisect for ANY regression, not just code bugs:
# - Performance regression (bisect + benchmark script)
# - Build breakage (bisect + compile check)
# - Test failure (bisect + specific test)

Stash: Save Work Without Committing

# Basic stash (saves tracked files only):
git stash                    # Stashes everything with default message
git stash push -m "WIP: OAuth login half-done"  # Named stash

# See what's stashed:
git stash list
# stash@{0}: On feature/auth: WIP: OAuth login half-done
# stash@{1}: On main: Quick experiment

# Restore stashed changes:
git stash pop               # Apply AND remove from stash list
git stash apply             # Apply BUT keep in stash list (safer)
git stash apply stash@{1}   # Restore a specific stash

# Stash specific files only:
git stash push -m "Config changes" src/config.js .env.example

# Include untracked AND ignored files:
git stash push -u -m "Everything"     # Includes new untracked files
git stash push -a -m "Really everything"  // Even ignored files!

# Show what changed in a stash:
git stash show -p stash@{0}   // Full diff of the stash

# Drop or clear:
git stash drop stash@{0}     // Remove one
git stash clear              // Remove ALL stashes

# Create a branch from a stash:
git stash branch fix-quick-bug stash@{0}
// Creates new branch "fix-quick-bug", applies stash, drops it if successful

Searching Through History

# Search COMMIT MESSAGES across all branches:
git log --all --grep="security" --oneline
git log --all --grep="fix" --grep="auth" --oneline  --and  (both words)
git log --all --grep="fix\|bug" --oneline       --or  (either word)

# Search CODE CONTENT through entire history:
git log -S "functionName" --oneline    // When text was added/removed
git log -G "pattern" --oneline         // Regex through diffs
git log -S "TODO" -p                   // Show actual diff where text appears

# Who wrote/changed this line?
git blame src/utils.js                  // Line-by-line author history
git blame -L 10,20 src/utils.js        // Lines 10-20 only
git blame -e src/utils.js             // Include email addresses
git blame -w src/utils.js             // Ignore whitespace changes

# Find which commit broke something (alternative to bisect for simple cases):
git log --oneline --since="2 weeks ago" -- src/auth.js
git log --oneline --author="Alice" -- src/api/

Recovering from Mistakes

# ❌ Committed to wrong branch:
git reset --soft HEAD~1        # Undo commit, keep changes staged
git checkout correct-branch
git commit                     # Re-commit on correct branch

# ❌ Accidentally committed sensitive data:
# If NOT pushed:
git rm secrets.json
git commit -m "Remove secrets"
# If already pushed: use BFG Repo Cleaner or git filter-repo

# ❌ Need to undo something?
git restore file.txt            // Discard uncommitted working directory changes
git restore --staged file.txt   // Unstage (keep changes)
git reflog                      // Recovery mode: find lost commits!

# Recover a deleted branch:
git reflog                       # Find SHA of branch tip
git branch recovered-branch abc1234

# Reset types explained:
git reset --soft HEAD~1   // Undo commit, keep changes STAGED
git reset --mixed HEAD~1   // Undo commit, keep changes UNSTAGED (default)
git reset --hard HEAD~1    // Undo commit, DISCARD all changes (dangerous!)

# Undo a specific file's changes to previous commit state:
git checkout HEAD~1 -- file.txt  // Get version from previous commit
// Or: git restore --source=HEAD~1 file.txt

Which advanced Git command here is new to you? What's your favorite Git trick?

Follow @armorbreak for more practical developer guides.

Promises, Async/Await, and Error Handling: The Complete Guide (2026)

Alex Chen — Fri, 12 Jun 2026 16:35:00 +0000

Promises, Async/Await, and Error Handling: The Complete Guide (2026)

Async JavaScript is everywhere — but most developers only scratch the surface. Here's the complete picture from callbacks to modern async patterns.

The Evolution of Async JavaScript

// Phase 1: Callbacks (the old way — avoid "callback hell")
fs.readFile('data.json', 'utf8', function(err, data) {
  if (err) return console.error(err);
  fs.writeFile('output.json', data, function(err) {
    if (err) return console.error(err);
    console.log('Done!');
    // Nesting deeper with each step = callback hell!
  });
});

// Phase 2: Promises (ES2015 — chainable, composable)
readFilePromise('data.json')
  .then(data => writeFilePromise('output.json', data))
  .then(() => console.log('Done!'))
  .catch(err => console.error(err)); // Single error handler!

// Phase 3: Async/Await (ES2017 — synchronous-looking code)
async function processFile() {
  try {
    const data = await readFilePromise('data.json');
    await writeFilePromise('output.json', data);
    console.log('Done!');
  } catch (err) {
    console.error(err);
  }
}
// This is the same as Phase 2 but reads top-to-bottom!

Promises Deep Dive

// Creating promises:
const myPromise = new Promise((resolve, reject) => {
  // Async operation here:
  const success = doSomething();
  if (success) resolve(resultValue);   // Fulfilled!
  else reject(errorReason);            // Rejected!
});

// Promise states:
// 1. Pending: Initial state, neither fulfilled nor rejected
// 2. Fulfilled: Operation completed successfully (.then fires)
// 3. Rejected: Operation failed (.catch fires)
// 4. Settled: Either fulfilled or rejected (final state, won't change)

// Static methods:

// Promise.resolve() / Promise.reject():
const resolved = Promise.resolve(42);           // Already fulfilled
const rejected = Promise.reject(new Error('fail')); // Already rejected

// Promise.all(): Run multiple promises, wait for ALL to settle
// ⚠️ If ANY rejects → entire Promise.all rejects immediately!
const results = await Promise.all([
  fetchUser(id),
  fetchPosts(id),
  fetchComments(id),
]);
// results = [user, posts, comments] — in order!

// Promise.allSettled(): Wait for ALL, never rejects (returns status for each)
const outcomes = await Promise.allSettled([
  maybeFails(),
  alsoMaybeFails(),
]);
outcomes.forEach(o => {
  if (o.status === 'fulfilled') use(o.value);
  else handleFailure(o.reason); // Doesn't throw!
});

// Promise.race(): Returns result/rejection of FIRST to settle
const result = await Promise.race([
  fetchFromPrimary(),
  timeoutAfter(3000), // Rejects after 3 seconds
]);

// Promise.any(): Returns result of FIRST to FULFILL (ignores rejections until all fail)
const firstSuccess = await Promise.any([
  tryServerA(),
  tryServerB(),
  tryServerC(),
]); // First one that works wins! All fail → AggregateError

// Chaining: Each .then() returns a new promise
fetch('/api/user')
  .then(res => res.json())         // Transform response
  .then(user => {                  // Use transformed value
    console.log(user.name);
    return user.id;                // Pass to next .then()
  })
  .then(userId => fetch(`/api/posts/${userId}`))
  .then(res => res.json())
  .then(posts => console.log(posts))
  .catch(err => {                   // Catches errors from ANY step above
    console.error('Failed:', err.message);
  })
  .finally(() => {                 // ALWAYS runs (success or failure)
    loadingSpinner.style.display = 'none';
  });

// Common mistake: Forgetting to return in .then():
fetch('/api/data')
  .then(res => res.json())        // ✅ Returns promise
  .then(data => {                 // ❌ No return! Next .then gets undefined
    processData(data);             // Fix: return processData(data)
  })
  .then(result => console.log(result)); // undefined!

Async/Await Mastery

// Basic syntax:
async function fetchData(url) {
  const response = await fetch(url);     // Pauses here until fetch resolves
  const data = await response.json();    // Then pauses here until json parses
  return data;
}

// Arrow async:
const getData = async () => { ... };

// Object method async:
const obj = { async fetch() { ... } };

// Class method async:
class Service { async load() { ... } }

// Parallel awaits vs sequential (CRITICAL performance difference):

// ❌ Sequential (SLOW — each waits for the previous):
async function getUserDataSlow(userId) {
  const user = await db.users.findById(userId);      // 100ms
  const posts = await db.posts.findByUser(userId);   // +150ms
  const comments = await db.comments.findFor(posts);  // +80ms
  return { user, posts, comments };                   // Total: ~330ms
}

// ✅ Parallel (FAST — all run simultaneously):
async function getUserDataFast(userId) {
  const [user, posts, comments] = await Promise.all([
    db.users.findById(userId),       // 100ms
    db.posts.findByUser(userId),      // 150ms (runs in parallel!)
    db.comments.findForPosts(userId), // 80ms (runs in parallel!)
  ]);
  return { user, posts, comments };     // Total: ~150ms (slowest one wins)
}

// Error handling patterns:

// Pattern 1: Try/catch around everything
async function safeOperation() {
  try {
    const data = await riskyCall();
    return { success: true, data };
  } catch (err) {
    logError(err);
    return { success: false, error: err.message };
  }
}

// Pattern 2: Individual error handling per operation
async function multiStep() {
  let user, posts;

  try {
    user = await fetchUser(); // If this fails...
  } catch (err) {
    user = getDefaultUser();  // ...use fallback instead of crashing
  }

  try {
    posts = await fetchPosts(user.id);
  } catch (err) {
    posts = []; // Empty array fallback
  }

  return { user, posts };
}

// Pattern 3: Higher-order error wrapper (reusable!)
function withFallback(fn, fallback) {
  return async (...args) => {
    try { return await fn(...args); }
    catch (err) { 
      console.warn(`${fn.name} failed, using fallback:`, err.message);
      return typeof fallback === 'function' ? fallback(...args) : fallback;
    }
  };
}

const safeFetch = withFallback(fetchData, []);
const safeUser = withFallback(getUser, { name: 'Guest' });

// Awaiting non-promise values (works fine):
const result = await 42;              // Resolves immediately to 42
const result = await null;            // Resolves to null
const result = await Promise.resolve(42); // Same as above

// Top-level await (in ES modules only):
// module.js (with "type": "module" in package.json):
const config = await fetchConfig();    // Works at top level!
console.log(config.apiKey);          // Waits for config before continuing

Advanced Patterns

// Retry pattern with exponential backoff:
async function retry(fn, options = {}) {
  const {
    maxAttempts = 3,
    baseDelay = 1000,
    maxDelay = 30000,
    backoff = 2,
    retryableErrors = ['ECONNRESET', 'ETIMEDOUT', 'ECONNREFUSED'],
  } = options;

  let lastError;

  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (err) {
      lastError = err;

      const isRetryable = retryableErrors.some(code =>
        err.code === code || err.message?.includes(code)
      );

      if (!isRetryable || attempt === maxAttempts) throw err;

      const delay = Math.min(baseDelay * Math.pow(backoff, attempt - 1), maxDelay);
      console.warn(`Attempt ${attempt}/${maxAttempts} failed, retrying in ${delay}ms`);
      await new Promise(r => setTimeout(r, delay));
    }
  }
}

// Usage:
const data = await retry(() => fetchFromAPI(endpoint), { maxAttempts: 5 });

// Timeout wrapper:
function withTimeout(promise, ms, error = new Error('Timeout')) {
  return Promise.race([
    promise,
    new Promise((_, reject) => setTimeout(() => reject(error), ms))
  ]);
}

// Usage:
const user = await withTimeout(fetchUser(id), 5000, new Error('DB query timed out'));

// Request concurrency limiter:
class ConcurrencyLimiter {
  constructor(maxConcurrent) {
    this.max = maxConcurrent;
    this.running = 0;
    this.queue = [];
  }

  async run(fn) {
    if (this.running >= this.max) {
      await new Promise(resolve => this.queue.push(resolve));
    }
    this.running++;
    try {
      return await fn();
    } finally {
      this.running--;
      if (this.queue.length > 0) {
        this.queue.shift()();
      }
    }
  }
}

const limiter = new ConcurrencyLimiter(5); // Max 5 concurrent requests
urls.forEach(url => limiter.run(() => fetchAndProcess(url)));

// Async iterator pattern (for streaming/pagination):
async function* paginate(apiFn, params) {
  let page = 1;
  while (true) {
    const result = await apiFn({ ...params, page, limit: 100 });
    yield result.items;
    if (result.items.length < 100 || page >= result.totalPages) break;
    page++;
  }
}

for await (const batch of paginate(fetchUsers, {})) {
  processBatch(batch); // Process 100 at a time
}

Common Mistakes & Anti-Patterns

// ❌ Anti-pattern #1: Fire-and-forget without error handling
async function updateUser(userId) {
  await db.users.update(userId, { name: 'New Name' }); // If this throws...
  sendEmailNotification(userId);                           // ...this NEVER runs!
}
// Fix: Wrap in try/catch or ensure errors propagate

// ❌ Anti-pattern #2: Unnecessary await
const userId = await req.user.id;  // req.user.id is NOT a promise!
// Remove await — it adds unnecessary microtask overhead

// ❌ Anti-pattern #3: Using await inside Promise constructor
new Promise(async (resolve, reject) => {  // DON'T DO THIS!
  const data = await fetchData();       // Errors here won't be caught by reject!
  resolve(data);
});
// Fix: Just make the outer function async instead

// ❌ Anti-pattern #4: Mixing callbacks and promises incorrectly
fs.readFile('file.txt', (err, data) => {
  // This callback doesn't return anything to a promise chain
});
// Fix: Use fs.promises.readFile or util.promisify(fs.readFile)

// ❌ Anti-pattern #5: Forgetting that map + async = fire-and-forget
const users = [1, 2, 3];
const results = users.map(async id => {  // Returns array of PROMISES, not values!
  return await fetchUser(id);
});
// Fix: await Promise.all(users.map(async id => await fetchUser(id)))

// ❌ Anti-pattern #6: catch blocks that swallow errors silently
try { await riskyOp(); } catch (e) { /* oops */ }  // Error disappears forever!
// Fix: At minimum: log it. Better: re-throw or handle properly.

What's your favorite async pattern? What async pitfall has bitten you before?

Follow @armorbreak for more practical developer guides.

Testing JavaScript: Practical Guide to Confident Code (2026)

Alex Chen — Thu, 11 Jun 2026 20:40:26 +0000

Testing JavaScript: Practical Guide to Confident Code (2026)

Testing isn't about catching bugs — it's about having the confidence to change code without fear. Here's how to write tests that actually matter.

The Testing Pyramid

                    ╱╲
                   ╱ E2E╲           ← Few, slow, expensive
                  ╱──────╲
                 ╱ Integration╲    ← Some, medium speed
                ╱──────────────╲
               ╱   Unit Tests    ╲ ← Many, fast, cheap
              ╱──────────────────╲

Rule of thumb:
- 70% Unit tests (fast, isolated)
- 20% Integration tests (test component interaction)
- 10% E2E tests (critical user flows only)

Unit test: Does this function work? (ms per test)
Integration: Do these modules work together? (seconds per test)
E2E: Can a user complete a purchase? (minutes per test)

Unit Testing with Vitest/Jest

// Setup (vitest.config.js or jest.config.js):
import { defineConfig } from 'vitest/config';
export default defineConfig({
  test: {
    environment: 'node',
    globals: true,
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
      include: ['src/**/*.js'],
      exclude: ['src/**/*.test.js', 'src/config/**'],
      thresholds: {
        branches: 80,
        functions: 80,
        lines: 80,
        statements: 80,
      },
    },
  },
});

// Basic unit test:
import { describe, it, expect, beforeEach } from 'vitest';
import { Calculator } from '../calculator.js';

describe('Calculator', () => {
  let calc;

  beforeEach(() => {
    calc = new Calculator();
  });

  describe('add()', () => {
    it('should add two positive numbers', () => {
      expect(calc.add(2, 3)).toBe(5);
    });

    it('should handle negative numbers', () => {
      expect(calc.add(-1, -1)).toBe(-2);
    });

    it('should handle decimal numbers', () => {
      expect(calc.add(0.1, 0.2)).toBeCloseTo(0.3); // Floating point!
    });

    it('should throw on non-number input', () => {
      expect(() => calc.add('a', 2)).toThrow('Numbers only');
    });
  });
});

// Async testing:
describe('API Service', () => {
  it('should fetch user data', async () => {
    const user = await userService.findById('abc123');
    expect(user).toBeDefined();
    expect(user.id).toBe('abc123');
  });

  it('should throw on not found', async () => {
    await expect(userService.findById('nonexistent'))
      .rejects.toThrow('User not found');
  });

  // Mocking external dependencies:
  it('should call API with correct params', async () => {
    const mockFetch = vi.fn().mockResolvedValue({
      json: async () => ({ id: '123', name: 'Test' })
    });

    global.fetch = mockFetch;
    const result = await apiClient.getUser('123');

    expect(mockFetch).toHaveBeenCalledWith('/api/users/123');
    expect(result.name).toBe('Test');
  });
});

Test Doubles: Mocks, Stubs & Spies

// Understanding when to use each:

// STUB: Replace real implementation with a fixed response
// Use when: You need to control dependencies' behavior deterministically
const dbStub = {
  findById: vi.fn()
    .mockResolvedValueOnce({ id: '1', name: 'Alice' })
    .mockResolvedValueOnce({ id: '2', name: 'Bob' })
    .mockRejectedValueOnce(new Error('DB error')),
};

// MOCK: Verify behavior (was it called? with what args?)
// Use when: You need to assert HOW your code uses dependencies
const emailServiceMock = {
  sendWelcomeEmail: vi.fn(),
};

await registerNewUser({ email: 'test@example.com' });
expect(emailServiceMock.sendWelcomeEmail).toHaveBeenCalledTimes(1);
expect(emailServiceMock.sendWelcomeEmail).toHaveBeenCalledWith(
  'test@example.com',
  'Welcome!'
);

// SPY: Wrap real function to track calls without replacing behavior
// Use when: You want to keep original behavior but verify usage
const realLogger = console.log;
const logSpy = vi.spyOn(console, 'log');

processData();
expect(logSpy).toHaveBeenCalledWith('Processing started');

// Best practices for mocking:
// ✅ Mock at boundaries (database, file system, network, time)
// ✅ Keep mocks close to the code they mock (same folder or __mocks__/)
// ❌ Don't mock everything — if you mock everything, you're testing nothing
// ❌ Don't mock implementation details — test behavior, not internals

// Time mocking (essential for timers/deadlines):
vi.useFakeTimers();
const callback = vi.fn();
setTimeout(callback, 5000);

// Fast-forward 5 seconds instantly!
vi.advanceTimersByTime(5000);
expect(callback).toHaveBeenCalled();

// Or advance tick by tick:
vi.advanceTimersByTime(1000);
expect(callback).not.toHaveBeenCalled(); // Not yet!

vi.advanceTimersByTime(4000);
expect(callback).toHaveBeenCalled(); // Now!
vi.useRealTimers(); // Always restore!

Integration Testing

// Test that components work together correctly:

describe('Auth Flow Integration', () => {
  // Use a test database (not production!)
  beforeAll(async () => {
    await testDb.migrate();
    await testDb.seed(['users', 'sessions']);
  });

  afterAll(async () => {
    await testDb.close();
  });

  it('should complete full login flow', async () => {
    // Step 1: Register
    const regRes = await request(app)
      .post('/api/auth/register')
      .send({ email: 'test@example.com', password: 'Password123!' })
      .expect(201);

    expect(regRes.body.data.email).toBe('test@example.com');
    expect(regRes.body.data.token).toBeDefined();

    // Step 2: Login with same credentials
    const loginRes = await request(app)
      .post('/api/auth/login')
      .send({ email: 'test@example.com', password: 'Password123!' })
      .expect(200);

    // Step 3: Access protected endpoint with token
    const profileRes = await request(app)
      .get('/api/profile')
      .set('Authorization', `Bearer ${loginRes.body.token}`)
      .expect(200);

    expect(profileRes.body.data.email).toBe('test@example.com');
  });

  it('should reject expired token', async () => {
    const expiredToken = jwt.sign({ sub: 'user1' }, secret, { expiresIn: '-1h' });

    await request(app)
      .get('/api/profile')
      .set('Authorization', `Bearer ${expiredToken}`)
      .expect(401);
  });
});

// Database integration with test containers:
// Using testcontainers-js for real DB in tests:
import { PostgreSqlContainer } from '@testcontainers/postgresql';

let container;
let pool;

beforeAll(async () => {
  container = await new PostgreSqlContainer().start();
  pool = new Pool({ connectionString: container.getConnectionUri() });
  await pool.query(`CREATE TABLE users (id UUID PRIMARY KEY, name TEXT)`);
});

afterAll(async () => {
  await pool.end();
  await container.stop();
});

What to Test (and What NOT to Test)

// ✅ TEST THIS:
// - Business logic and calculations
// - Authentication and authorization rules
// - Input validation and sanitization
// - Error handling paths (what happens when things go wrong?)
// - Critical user flows (login, checkout, data export)
// - Edge cases: empty arrays, null values, boundary numbers, unicode strings
// - Performance-sensitive operations (are they within acceptable time?)

// ❌ DON'T TEST THIS:
// - Third-party libraries (they have their own tests)
// - Framework internals (Express routing works, don't test it)
// - Implementation details (private methods, internal state)
// - Trivial getters/setters (one-liners)
// - Things you can't control (external APIs without mocking)

// The "useful test" litmus test:
// If this test fails, will it tell me exactly what's wrong?
// If I refactor the code (without changing behavior), will this test still pass?
// If the answer to both is YES → good test!
// If either is NO → reconsider the test.

// Test naming convention that tells a story:
it('should deny access when token has expired');         // Clear!
it('auth-001');                                         // Unclear — what does this test?
it('returns 401 for expired tokens');                     // Better but vague
it('POST /api/protected → 401 when JWT exp < now');     // BEST — specific + actionable

What's your testing philosophy? TDD first, or test after? How much coverage do you aim for?

Follow @armorbreak for more practical developer guides.

Debugging JavaScript: From console.log to Pro (2026)

Alex Chen — Thu, 11 Jun 2026 20:39:04 +0000

Debugging JavaScript: From console.log to Pro (2026)

Every developer spends more time debugging than writing code. The difference between juniors and seniors isn't writing bug-free code — it's finding bugs faster.

Beyond console.log

// You already know these:
console.log('Basic log');
console.error('Error message');
console.warn('Warning message');

// But these are MORE useful:

// Formatted logging (%s=string, %o=object, %d=number, %c=CSS style):
console.log('%c ERROR %c User %s not found', 
  'color: red; font-weight: bold; background: #ffe0e0; padding: 2px 6px;',
  'color: blue;', userId);
// Output: Red "ERROR" badge + blue userId

// Table view for arrays of objects:
const users = [
  { id: 1, name: 'Alice', role: 'admin', active: true },
  { id: 2, name: 'Bob', role: 'user', active: false },
];
console.table(users, ['name', 'role']); // Only show selected columns!

// Grouping related logs:
console.group('User Authentication');
  console.log('Step 1: Validate token');
  console.log('Step 2: Fetch user');
  console.log('Step 3: Check permissions');
console.groupEnd();
// Collapsible in browser DevTools!

// Timing operations:
console.time('API call');
await fetch('/api/data');
console.timeEnd('API call'); // Output: "API call: 243.45ms"

// Assert (log only if condition is false):
function processUser(user) {
  console.assert(user.email, 'User must have email:', user); // Shows stack trace!
  // ... rest of function
}

// Trace (shows how you got here):
function helper() {
  console.trace('Called from:');
}
function main() {
  helper(); // Shows full call stack leading to this point
}

// Count (track how many times something runs):
let renderCount = 0;
function render() {
  renderCount++;
  console.count('render called'); // "render called: 1", "render called: 2", ...
}

Chrome DevTools Debugger

// Instead of adding/removing console.logs, use the debugger statement:
function complexCalculation(a, b) {
  const sum = a + b;
  debugger; // Pauses execution here! Inspect variables in DevTools.
  return sum * 2;
}

// Conditional breakpoint (in DevTools Sources panel):
// Right-click line number → "Add conditional breakpoint"
// Enter: count > 100  → Only pauses when condition is true
// Enter: user.id === 'abc123' → Only pauses for specific user

// Logpoint (non-breaking console.log at breakpoint):
// Right-click → "Add logpoint"
// Enter: 'User ID:', userId  → Logs without pausing!
// Great for production debugging where you can't stop execution

// XHR/Fetch breakpoints (DevTools → Sources → XHR breakpoints):
// Set to break on any URL containing "/api/"
// Or break on specific request types

// DOM breakpoints:
// Select element in Elements tab → right-click → Break on:
// - Subtree modifications (when children change)
// - Attribute modifications (when attributes change)
// - Node removal (when element is deleted)
// Invaluable for tracking down rogue JS modifying your DOM!

// Console API tricks available in DevTools:
$0              // Currently selected element in Elements tab
$1              // Previously selected element
$('button')     // querySelector alias
$$('.item')     // querySelectorAll alias
copy(data)      // Copy to clipboard
keys(object)    // Show object keys
values(object)  // Show object values
monitor(fn)     // Log every time fn is called with arguments
monitorEvents(element, 'click')  // Log all click events on element

Node.js Debugging

// Built-in inspector (Node.js 6.3+):
// node --inspect app.js
// Then open chrome://inspect in Chrome and connect!

// Or inspect on first line:
// node --inspect-brk app.js

// Debugging with VS Code:
// Create .vscode/launch.json:
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Server",
      "program": "${workspaceFolder}/src/server.js",
      "skipFiles": ["<node_internals>/**"],
      "env": { "NODE_ENV": "development" }
    },
    {
      "type": "node",
      "request": "attach",
      "name": "Attach to Running",
      "port": 9229,
      "restart": true,
      "stopOnEntry": false
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Run Current File",
      "program": "${file}",
      "console": "integratedTerminal"
    }
  ]
}

// Useful launch configurations:

// Debug Mocha tests:
{
  "type": "node",
  "request": "launch",
  "name": "Mocha All",
  "program": "${workspaceFolder}/node_modules/.bin/mocha",
  "args": ["--timeout", "10000", "${workspaceFolder}/test/**/*.js"]
}

// Debug with environment-specific .env:
// Install: npm install dotenv-cli
{
  "type": "node",
  "request": "launch",
  "envFile": "${workspaceFolder}/.env.development",
  "program": "${workspaceFolder}/src/server.js"
}

Source Maps & Production Debugging

// Source maps connect your compiled/minified code back to original source:
// tsconfig.json:
{
  "compilerOptions": {
    "sourceMap": true,
    "sourceRoot": "./src",
    "inlineSourceMap": false,   // Separate .map file (don't inline in prod!)
    "mapRoot": "./dist/maps"
  }
}

// webpack/vite config:
module.exports = {
  devtool: 'source-map',        // Best for production (separate file)
  // devtool: 'cheap-module-source-map',  // Faster rebuilds for dev
};

// NEVER upload source maps to public servers in production!
// They expose your entire source code.
// Options:
// 1. Don't generate source maps in production builds
// 2. Generate but don't deploy them (keep internally for error reporting)
// 3. Use a service that requires authentication to access maps (Sentry, etc.)

// Error tracking with source map support:
// Sentry automatically applies source maps when you upload them:
// npx @sentry/cli sourcemaps upload ./dist
// Now errors show the ORIGINAL code line, not minified code!

Common Bugs & How to Find Them Fast

// Bug #1: "undefined is not a function" / "Cannot read property of undefined"
// Cause chain: variable is undefined → accessing property → crash
// Quick fix: Add optional chaining to find where it breaks:
// Before: data.user.address.city
// After:  data?.user?.address?.city
// If this doesn't crash → the problem is somewhere in that chain

// Bug #2: Async/await error swallowed silently
async function broken() {
  const data = await fetch('/api'); // If this throws...
  processData(data);                 // ...this never runs, but no error shown!
}
// Fix: Always use try/catch or .catch():
async function fixed() {
  try {
    const data = await fetch('/api');
    processData(data);
  } catch (err) {
    console.error('Fetch failed:', err); // NOW you see the error!
  }
}
// Or add global handler:
process.on('unhandledRejection', (reason) => {
  console.error('Unhandled rejection:', reason);
});

// Bug #3: Race conditions
let cachedData;
async function getData() {
  if (!cachedData) {
    cachedData = await slowFetch(); // Two calls arrive simultaneously!
  }                                   // Both see null → both fetch!
  return cachedData;
}
// Fix: Use promise caching (not value caching):
let fetchPromise;
async function getDataFixed() {
  if (!fetchPromise) {
    fetchPromise = slowFetch().finally(() => { fetchPromise = null; });
  }
  return fetchPromise;
}
// Now concurrent calls share the SAME promise!

// Bug #4: Memory leak detection
// In DevTools → Memory tab:
// 1. Take heap snapshot
// 2. Do the operation that might leak
// 3. Take another heap snapshot
// 4. Compare snapshots → objects growing = leak suspects
// Look for "(detached)" elements — DOM nodes referenced by JS but removed from page

// Bug #5: Off-by-one errors in loops
for (let i = 0; i <= array.length; i++) { // ≤ instead of < !
  // Crashes on last iteration (array[length] = undefined)
}
// Fix: Use for...of when you don't need index:
for (const item of array) { /* safe */ }
// Or use .forEach(), .map(), .filter() — no index bugs possible

What's your favorite debugging technique? What's the weirdest bug you've ever found?

Follow @armorbreak for more practical developer guides.

Node.js Event Loop: Understanding the Async Heartbeat (2026)

Alex Chen — Thu, 11 Jun 2026 20:37:51 +0000

Node.js Event Loop: Understanding the Async Heartbeat (2026)

The event loop is what makes Node.js "async" and "non-blocking". Understanding it isn't academic — it's the difference between an app that handles 10 connections and one that handles 10,000.

The Mental Model

Think of the event loop as a loop that keeps checking:

┌─────────────────────────────────────┐
│  1. Run any TIMERS (setTimeout, etc) │
│  2. Run PENDING CALLBACKS           │
│  3. POLL for new I/O events         │
│  4. Run SET IMMEDIATE callbacks     │
│  5. CLOSE callbacks                 │
│  → Back to step 1                   │
└─────────────────────────────────────┘

Key insight: JavaScript is SINGLE-THREADED.
The event loop is just a clever scheduling mechanism.
Only ONE thing runs at a time.
"Async" means "I'll come back to this later when data arrives",
not "this runs on another thread".

The 6 Phases in Detail

// Each iteration of the event loop has 6 phases:
// Timers → Pending Callbacks → Idle/Prepare → Poll → Check → Close Callbacks

// Phase 1: TIMERS
// setTimeout and setInterval callbacks run here
// ⚠️ NOT guaranteed to run at exact time! Just "no earlier than"
console.log('Start');
setTimeout(() => console.log('Timer: 0ms'), 0);
setTimeout(() => console.log('Timer: 100ms'), 100);
console.log('End');
// Output: Start → End → Timer: 0ms → Timer: 100ms
// Even 0ms timer doesn't run immediately!

// Phase 2: PENDING CALLBACKS
// I/O error callbacks from previous loop iterations
// Usually handled by system internals

// Phase 3: IDLE/PREPARE
// Internal use only (libuv internals)
// prepare: run setImmediate() callbacks scheduled here

// Phase 4: POLL (the most important phase!)
// Retrieves new I/O events
// - If poll queue not empty → process callbacks
// - If empty AND no timers → wait for I/O (may block here!)
// - If empty BUT has timers → move to next phase (don't block)

// Phase 5: CHECK (setImmediate)
// Runs setImmediate() callbacks
// This is why setImmediate beats setTimeout(fn, 0):
setImmediate(() => console.log('immediate'));
setTimeout(() => console.log('timeout'), 0);
// Output: immediate → timeout (always! in same callback context)

// Phase 6: CLOSE CALLBACKS
// socket.on('close', ...) etc.

Microtasks vs Macrotasks

// CRITICAL distinction that affects execution order:

// MACROTASKS (run between event loop phases):
// setTimeout, setInterval, setImmediate, I/O callbacks, UI rendering

// MICROTASKS (run after each macrotask completes, before next macrotask):
// Promise.then/.catch/.finally, queueMicrotask(), MutationObserver

// Execution order example:
console.log('1: script start');

setTimeout(() => {
  console.log('2: setTimeout');
}, 0);

Promise.resolve()
  .then(() => console.log('3: promise 1'))
  .then(() => console.log('4: promise 2'));

queueMicrotask(() => console.log('5: microtask'));

console.log('6: script end');

// Output order:
// 1: script start        ← synchronous code first
// 6: script end           ← synchronous code finishes
// 3: promise 1            ← microtask queue drains completely
// 5: microtask            ← before next macrotask
// 4: promise 2            ← still draining microtasks!
// 2: setTimeout          ← now macrotask runs

// ⚠️ Microtask infinite loop blocks EVERYTHING:
Promise.resolve().then(async function loop() {
  console.log('stuck in microtask!');
  await Promise.resolve(); // Still a microtask!
  return loop(); // Never lets event loop continue!
});
// No timers fire, no I/O processes, nothing else works!

Practical Implications

// Problem #1: Blocking the event loop
function blockingOperation() {
  // CPU-intensive work blocks everything:
  const start = Date.now();
  while (Date.now() - start < 5000) {
    // Spinning CPU for 5 seconds
    // During this time: NO requests handled, NO timers fire, NOTHING
  }
}
// Fix: Use Worker threads or break into chunks with setImmediate

// Fix: Yield control periodically
function nonBlockingWork(items, callback) {
  let index = 0;

  function processChunk() {
    const chunkEnd = Math.min(index + 1000, items.length);
    for (; index < chunkEnd; index++) {
      heavyProcessing(items[index]);
    }

    if (index < items.length) {
      setImmediate(processChunk); // Let other things run between chunks
    } else {
      callback();
    }
  }

  processChunk();
}

// Problem #2: Starving I/O with CPU work
// If you have constant computation, I/O callbacks never get to run!
// Solution: Worker threads for CPU work:
const { Worker } = require('worker_threads');
const worker = new Worker('./heavy-computation.js', { workerData: largeDataset });
worker.on('message', (result) => {
  console.log('Result:', result); // Main thread stays responsive!
});

// Problem #3: Unhandled rejections in microtasks
// A rejected promise without .catch() creates a "unhandled rejection"
// But it's reported asynchronously (via microtask), which can be confusing:
Promise.reject(new Error('oops'));
console.log('This prints BEFORE the unhandled rejection warning');
// Because the rejection goes through microtask queue first

// Best practice: Always handle errors at each level:
async function safeAPICall() {
  try {
    const data = await fetch('/api/data');
    return await data.json();
  } catch (err) {
    console.error('API call failed:', err.message);
    throw err; // Re-throw if caller needs to know
  }
}

// Problem #4: process.nextTick vs setImmediate vs setTimeout
process.nextTick(() => console.log('nextTick'));   // Before all phases (microtask-like)
setImmediate(() => console.log('setImmediate'));      // After poll phase
setTimeout(() => console.log('setTimeout 0'), 0);     // After timers phase

// Order: nextTick → setImmediate → setTimeout(0)
// Use nextTick for: cleanup after current operation (must run before I/O)
// Use setImmediate for: "after I/O but before timers" operations
// Use setTimeout for: actual delayed execution (minimum 1ms even if 0)

Debugging Event Loop Issues

// Detect if your event loop is blocked:
let lastTime = process.hrtime.bigint();
const BLOCK_THRESHOLD_MS = 100; // Alert if loop blocked > 100ms

function checkLoopDelay() {
  const now = process.hrtime.bigint();
  const delayMs = Number(now - lastTime) / 1_000_000;
  if (delayMs > BLOCK_THRESHOLD_MS) {
    console.warn(`Event loop blocked for ${delayMs.toFixed(0)}ms`);
  }
  lastTime = now;
}

// Run this check frequently via interval:
setInterval(checkLoopDelay, 1000);

// Or use built-in diagnostics:
// --enable-source-maps flag for better async stack traces
// NODE_DEBUG=async_hooks node app.js  // See internal async operations

// Performance hooks (Node.js 12+):
const { performance, PerformanceObserver } = require('perf_hooks');

const obs = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'node') {
      console.log(`${entry.name}: ${entry.duration}ms`);
    }
  }
});

obs.observe({ entryTypes: ['node'] });

// Measure specific async operations:
performance.mark('db-query-start');
await db.query('SELECT * FROM users');
performance.mark('db-query-end');
performance.measure('database query', 'db-query-start', 'db-query-end');

What's the most confusing aspect of the event loop? Have you ever debugged a blocking issue?

Follow @armorbreak for more practical developer guides.

JavaScript Performance: Making Your Apps Fast (2026)

Alex Chen — Thu, 11 Jun 2026 20:36:44 +0000

JavaScript Performance: Making Your Apps Fast (2026)

Performance isn't about premature optimization — it's about understanding what makes JavaScript slow and knowing how to fix it when it matters.

Measuring Performance Correctly

// ❌ Wrong ways to measure:
const start = Date.now();        // Low resolution (ms only)
doSomething();
console.log(Date.now() - start); // Inaccurate

// ✅ Right way: Performance API (microsecond precision!)
const { performance, PerformanceObserver } = require('perf_hooks');

// Measure a specific operation:
function measure(name, fn) {
  const start = performance.now();
  const result = fn();
  const duration = performance.now() - start;
  console.log(`${name}: ${duration.toFixed(2)}ms`);
  return result;
}

// Mark + measure for complex flows:
performance.mark('fetch-start');
await fetchData();
performance.mark('parse-start');
parseData();
performance.mark('render-start');
renderUI();
performance.mark('done');

performance.measure('fetch', 'fetch-start', 'parse-start');
performance.measure('parse', 'parse-start', 'render-start');
performance.measure('render', 'render-start', 'done');

// Get all measurements:
const entries = performance.getEntriesByType('measure');
entries.forEach(e => console.log(`${e.name}: ${e.duration.toFixed(2)}ms`));

// Observer pattern (non-blocking monitoring):
const obs = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      console.warn(`Slow operation: ${entry.name} took ${entry.duration.toFixed(0)}ms`);
    }
  }
});
obs.observe({ entryTypes: ['measure'] });

The V8 Engine & Hidden Classes

// V8 uses "hidden classes" to optimize property access.
// When objects have the same shape → same hidden class → optimized!

// ✅ Same shape (FAST):
class Point {
  constructor(x, y) { this.x = x; this.y = y; }
}
const points = Array.from({ length: 100000 }, () => new Point(
  Math.random(), Math.random()
));
// All Point instances share the same hidden class → blazing fast!

// ❌ Different shapes (SLOW):
const mixed = [
  { x: 1, y: 2 },
  { x: 1, y: 2, z: 3 },     // Different shape!
  { x: 1 },                   // Different shape!
  { x: 1, y: 2, color: 'red' } // Different shape!
];
// Each object gets its own hidden class → deoptimized access!

// Rule: Initialize ALL properties in the constructor,
// even if they're null/undefined initially.
// Don't add properties after construction in hot loops.

// Arrays: Use typed arrays for numeric data:
const regularArray = [1, 2, 3, 4, 5];           // Generic array
const typedArray = new Float64Array([1, 2, 3, 4, 5]); // Typed, contiguous memory
// Typed arrays are 3-10x faster for numeric operations and use less memory!

Async Performance Patterns

// ❌ Sequential awaits (slow — each waits for the previous):
async function getUserData(userId) {
  const user = await db.users.findById(userId);      // Wait...
  const posts = await db.posts.findByUser(userId);   // Then wait...
  const comments = await db.comments.findFor(posts);  // Then wait...
  return { user, posts, comments };
}
// Total time: sum of all three operations

// ✅ Parallel awaits (fast — all run simultaneously):
async function getUserDataFast(userId) {
  const [user, posts, comments] = await Promise.all([
    db.users.findById(userId),
    db.posts.findByUser(userId),
    db.comments.findForPosts(userId),
  ]);
  return { user, posts, comments };
}
// Total time: max of the three operations (usually 3x faster!)

// ✅ Concurrent with limit (don't overwhelm external APIs):
async function fetchAll(urls, concurrency = 5) {
  const results = [];
  const executing = [];

  for (const url of urls) {
    const promise = fetch(url).then(r => r.json()).then(data => {
      results.push({ url, data });
      executing.splice(executing.indexOf(promise), 1);
    });

    executing.push(promise);
    if (executing.length >= concurrency) {
      await Promise.race(executing); // Wait for one to finish before starting next
    }
  }

  await Promise.all(executing); // Wait for remaining
  return results;
}

// Worker threads for CPU-intensive tasks:
const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');

if (isMainThread) {
  function runInWorker(path, data) {
    return new Promise((resolve, reject) => {
      const worker = new Worker(__filename, { workerData: data });
      worker.on('message', resolve);
      worker.on('error', reject);
      worker.on('exit', (code) => {
        if (code !== 0) reject(new Error(`Worker stopped with code ${code}`));
      });
    });
  }

  async function processLargeDataset(dataset) {
    const result = await runInWorker('./heavy-computation.js', dataset);
    return result;
  }
} else {
  // This runs in the worker thread (doesn't block main event loop!)
  const result = heavyComputation(workerData);
  parentPort.postMessage(result);
}

Memory Management & Leaks

// Common memory leak patterns:

// Leak #1: Event listeners never removed
function setupLeak() {
  const element = document.getElementById('button');
  element.addEventListener('click', () => doSomething());
  // If this function is called repeatedly without cleanup → leak!
}
// Fix: Store reference and remove later, or use AbortController:
function setupSafe() {
  const controller = new AbortController();
  const element = document.getElementById('button');
  element.addEventListener('click', () => doSomething(), { signal: controller.signal });
  // Cleanup: controller.abort() removes all listeners at once
  return controller; // Call .abort() when done
}

// Leak #2: Closures holding references
function createLeakyFunction() {
  const hugeData = new Array(1000000).fill('data'); // Large array
  return function() {
    console.log(hugeData[0]); // Closure keeps hugeData alive forever!
  };
}
// Fix: Null out large references after use:
function createSafeFunction() {
  let hugeData = new Array(1000000).fill('data');
  return function() {
    const result = hugeData[0];
    hugeData = null; // Release reference!
    return result;
  };
}

// Leak #3: Map/Set as caches without bounds
const cache = new Map();
function getData(id) {
  if (!cache.has(id)) cache.set(id, fetchHugeData(id)); // Grows forever!
  return cache.get(id);
}
// Fix: Use LRU cache or set max size:
const MAX_CACHE_SIZE = 1000;
function getCachedData(id) {
  if (!cache.has(id)) {
    if (cache.size >= MAX_CACHE_SIZE) {
      // Remove oldest entry (Map preserves insertion order)
      const oldestKey = cache.keys().next().value;
      cache.delete(oldestKey);
    }
    cache.set(id, fetchHugeData(id));
  }
  return cache.get(id);
}

// Monitoring memory usage:
setInterval(() => {
  const mem = process.memoryUsage();
  console.log({
    rss: `${(mem.rss / 1024 / 1024).toFixed(0)}MB`,   // Resident Set Size
    heapUsed: `${(mem.heapUsed / 1024 / 1024).toFixed(0)}MB`,
    heapTotal: `${(mem.heapTotal / 1024 / 1024).toFixed(0)}MB`,
    external: `${(mem.external / 1024 / 1024).toFixed(0)}MB`,
  });
}, 30000);

// Force garbage collection (only with --expose-gc flag):
if (global.gc) global.gc();

DOM Performance

// ❌ Slow: Multiple DOM operations (reflow + repaint each time!)
for (let i = 0; i < 1000; i++) {
  const div = document.createElement('div');
  div.textContent = `Item ${i}`;
  document.body.appendChild(div); // Reflow + repaint every iteration!
}

// ✅ Fast: Batch DOM operations (single reflow + repaint)
const fragment = document.createDocumentFragment();
for (let i = 0; i < 1000; i++) {
  const div = document.createElement('div');
  div.textContent = `Item ${i}`;
  fragment.appendChild(div); // No reflow! Fragment is not in DOM yet.
}
document.body.appendChild(fragment); // Single reflow + repaint

// ✅ Even faster: innerHTML for bulk content (one parse operation):
document.body.innerHTML += `<div>${items.map(i => `Item ${i}`).join('</div><div>')}</div>`;

// Layout thrashing: Reading/writing alternately causes multiple reflows
// ❌ Bad (layout thrashing):
elements.forEach(el => {
  el.style.height = el.scrollHeight + 'px'; // Read → Write (reflow!)
});

// ✅ Good (batch reads, then batch writes):
const heights = elements.map(el => el.scrollHeight); // Read all first
elements.forEach((el, i) => {
  el.style.height = heights[i] + 'px';            // Write all after
});

// requestAnimationFrame for visual updates:
function animateScroll(targetY) {
  function step() {
    const currentY = window.scrollY;
    const diff = targetY - currentY;
    if (Math.abs(diff) < 1) return;
    window.scrollTo(0, currentY + diff * 0.1);
    requestAnimationFrame(step); // Browser decides optimal timing
  }
  requestAnimationFrame(step);
}

Quick Wins Checklist

Before optimizing anything:

1. Profile first! Never guess where the bottleneck is
2. Optimize the critical path (what user sees first)
3. Common quick wins:
   □ Defer non-critical JS (<script defer>, dynamic import())
   □ Minify + compress assets (gzip/brotli)
   □ Add caching headers (Cache-Control, ETag)
   □ Lazy-load images (loading="lazy", IntersectionObserver)
   □ Use CSS containment (contain: layout paint)
   □ Virtualize long lists (react-virtualized, etc.)
   □ Debounce/throttle scroll/resize/input handlers
   □ Use web workers for heavy computation
   □ Enable HTTP/2 or HTTP/3 on your server
   □ Preload critical resources (<link rel="preload">)

4. What NOT to optimize:
   - Code that runs once at startup
   - Error handling paths (rarely executed)
   - Developer experience over micro-optimizations
   - Anything you haven't measured

What's the biggest performance win you've ever achieved? What performance myth drives you crazy?

Follow @armorbreak for more practical developer guides.

REST API Design: Building APIs That Developers Love (2026)

Alex Chen — Thu, 11 Jun 2026 20:35:35 +0000

REST API Design: Building APIs That Developers Love (2026)

A great API is one that developers enjoy using. It's intuitive, consistent, well-documented, and forgiving of mistakes. Here's how to build one.

Core Design Principles

1. Consistency: If /users returns {id, name}, then /posts should use the same format
2. Simplicity: Fewer endpoints doing more (filtering, sorting, pagination) is better
3. Predictability: Same input → same output, every time
4. Discoverability: The API should guide developers (links, errors with next steps)
5. Performance: Default to efficient; allow opt-in for expensive operations

URL & Resource Naming

// Use NOUNS not verbs (URLs are resources, not actions):
GET    /users              // List users
GET    /users/123          // Get specific user
POST   /users              // Create user
PUT    /users/123          // Full update user
PATCH  /users/123          // Partial update user
DELETE /users/123          // Delete user

// ❌ Bad: Verbs in URLs
// GET    /getUsers
// POST   /createUser
// POST   /deleteUser?id=123

// ❌ Bad: CRUD in URL
// POST   /users/create
// PUT   /users/update/123

// Nesting — when to nest vs flatten:
// Rule: Nest only if the child has NO meaning without the parent:
GET    /users/123/orders                    // ✅ Orders belong to a specific user
GET    /orders?userId=123                    // Also valid (preferred for many results)
// Avoid deep nesting (>2 levels):
// GET /users/123/orders/456/items/789       // ❌ Too deep!
// GET /items?orderId=456                    // ✅ Flatten it

// Pluralize resource names consistently:
/users     // NOT /user/
/posts      // NOT /post/
/categories // NOT /category/

// Use kebab-case for URL paths:
/user-profiles           // NOT /userProfiles or /user_profiles
/pending-orders          // NOT /pendingOrders
/api/v1/active-users     // Clear versioning + clear path

Request & Response Format

// Standard response envelope (always wrap!):
{
  "success": true,
  "data": {
    "id": "uuid-123",
    "name": "Alice",
    "email": "alice@example.com"
  },
  "meta": {
    "requestId": "req-abc123",
    "timestamp": "2026-06-12T04:33:00Z"
  }
}

// List response with pagination:
{
  "success": true,
  "data": [ /* items */ ],
  "meta": {
    "page": 1,
    "limit": 20,
    "total": 147,
    "totalPages": 8,
    "hasNext": true,
    "hasPrev": false
  }
}

// Error response (consistent structure across ALL errors):
{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The request data is invalid",
    "details": [
      { "field": "email", "message": "Must be a valid email address" },
      { "field": "password", "message": "Must be at least 12 characters" }
    ],
    "incidentId": "err-def456",        // For support lookup
    "documentationUrl": "https://docs.api.com/errors/validation",
    "retryable": false                  // Can client retry this request?
  },
  "meta": {
    "requestId": "req-abc123",
    "timestamp": "2026-06-12T04:33:00Z"
  }
}

Query Parameters for Filtering, Sorting & Pagination

// Filtering: Use query parameters, never nested objects in URLs:
GET /api/v1/posts?status=published&author=alice&tag=javascript&year=2026

// Implementation:
function parseFilters(query, allowedFilters) {
  const filters = {};
  for (const [key, value] of Object.entries(query)) {
    if (!allowedFilters.includes(key)) continue;

    // Support comma-separated values for array params:
    if (typeof value === 'string' && value.includes(',')) {
      filters[key] = value.split(',');
    } else {
      filters[key] = value;
    }
  }
  return filters;
}

// Allowed filters per endpoint:
const postFilters = ['status', 'author', 'tag', 'year', 'search', 'after', 'before'];

// Sorting: sort=field:direction (default direction varies by field):
GET /api/v1/posts?sort=createdAt:desc,title:asc

// Parse sorting:
function parseSort(sortParam, allowedFields) {
  const defaults = { field: 'createdAt', direction: 'desc' };
  if (!sortParam) return defaults;

  const [field, direction = 'desc'] = sortParam.split(':');
  if (!allowedFields.includes(field)) return defaults; // Ignore invalid fields!

  return { 
    field, 
    direction: ['asc', 'desc'].includes(direction) ? direction : 'desc' 
  };
}

// Pagination: Cursor-based (preferred for large datasets) OR offset-based:
// Offset-based (simple, good for small datasets):
GET /api/v1/posts?page=2&limit=20

// Cursor-based (efficient for large/real-time datasets):
GET /api/v1/posts?limit=20&cursor=eyJpZCI6MTAwfQ==

// Response includes cursor for next page:
{
  "data": [...],
  "pagination": {
    "next": "eyJpZCI6MTIwfQ==",   // Base64 cursor for next page
    "prev": null,                 // No previous page on first page
    "remaining": 127             // Items remaining after this page
  }
}

// Field selection (reduce payload size):
GET /api/v1/posts?fields=id,title,createdAt,author.name
// Only return specified fields (supports dot notation for nested!)

HTTP Methods & Status Codes

// Method usage rules:
// GET    — Must be idempotent + safe (no side effects). Never use body.
// PUT    — Idempotent (calling twice = calling once)
// POST   — Not idempotent (creates new resource each time)
// PATCH  — Not necessarily idempotent (partial updates)
// DELETE — Idempotent (deleting twice = deleting once)

// Status codes — use them correctly!
// 2xx Success:
200 OK              // Standard success (GET, PATCH, PUT)
201 Created         // Resource created (POST). Include Location header!
202 Accepted        // Async processing started. Return job ID/status endpoint.
204 No Content      // Success but no body (DELETE often uses this)

// 3xx Redirect:
301 Moved Permanently // Permanent redirect (use new URL)
304 Not Modified     // Client cache is still valid (use ETag/If-None-Match)

// 4xx Client Errors:
400 Bad Request      // Malformed syntax, invalid data
401 Unauthorized     // Not authenticated (no token / bad token)
403 Forbidden        // Authenticated but not allowed (wrong role)
404 Not Found        // Resource doesn't exist
405 Method Not Allowed // Wrong HTTP method for this endpoint
409 Conflict         // State conflict (duplicate email, concurrent edit)
422 Unprocessable Entity // Valid format but semantic error (validation failure)
429 Too Many Requests // Rate limited. Include Retry-After header.

// 5xx Server Errors:
500 Internal Server Error // Unexpected server error (log incident ID!)
502 Bad Gateway         // Upstream service unavailable
503 Service Unavailable // Temporary overload/maintenance
504 Gateway Timeout     // Upstream didn't respond in time

// ⚠️ Common mistakes:
// - Using 200 for errors (breaks clients expecting success body)
// - Using 401 for "not found" (401 = auth issue, 404 = missing resource)
// - Using 500 for validation failures (use 400 or 422)
// - Forgetting 201 Location header on creation

Versioning Strategy

// Option 1: URL path versioning (most common, clearest):
/api/v1/users
/api/v2/users  // Breaking change? New version.

// Option 2: Header versioning (cleaner URLs):
Accept: application/vnd.myapi.v2+json

// Option 3: Query param versioning (simplest, least favored):
/api/users?v=2

// Versioning best practices:
// - Start with v1 from day one (even if you think you won't need it)
// - Use MAJOR versions only (v1, v2) — no v1.1, v1.2 in URLs
// - Support old versions for at least 6 months after releasing new ones
// - Document breaking changes clearly
// - Non-breaking changes (new fields, new endpoints) don't need version bump

Authentication & Rate Limiting

// API key pattern (for server-to-server):
// Headers:
X-API-Key: sk_live_abc123
X-Request-ID: req-unique-id  // Client-generated for tracing

// Bearer token (OAuth2/JWT):
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

// Rate limiting headers (include in EVERY response):
HTTP/1.1 200 OK
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 998
X-RateLimit-Reset: 1718187600  // Unix timestamp when limit resets
Retry-After: 60               // On 429: seconds until retry

// Implement rate limiting:
const rateLimits = {
  authenticated: { windowMs: 60 * 1000, max: 1000 },  // 1000/min for logged-in
  unauthenticated: { windowMs: 60 * 1000, max: 100 },  // 100/min for anonymous
  sensitive: { windowMs:15 * 60 * 1000, max: 5 },     // Auth endpoints: 5/15min
};

What API design principle matters most to you? What's the worst API you've had to work with?

Follow @armorbreak for more practical developer guides.

Regular Expressions: The Guide I Always Wanted (2026)

Alex Chen — Wed, 10 Jun 2026 20:39:29 +0000

Regular Expressions: The Guide I Always Wanted (2026)

Regex looks like gibberish until it clicks — then it's a superpower. Here's the guide that makes regex actually make sense.

The Mental Model

Think of regex as a pattern-matching machine:

Input string:  "hello@example.com"
Pattern:       \w+@\w+\.\w+

The engine scans left-to-right, trying to match your pattern
at each position. When the full pattern matches → SUCCESS!

Key insight: Regex isn't about "finding text" — it's about
defining the SHAPE of what you're looking for.

Character Classes: What Are We Matching?

// Literal characters (match exactly)
/hello/           // Matches "hello" in "say hello there"

// Dot (wildcard) — matches ANY single character except newline
/h.t/             // "hat", "hot", "hit", but NOT "h" or "ht"

// Character classes — match ONE character from a set:
/[aeiou]/         // Any vowel
/[a-z]/           // Any lowercase letter
/[A-Z]/           // Any uppercase letter
/[0-9]/           // Any digit (same as /\d/)
/[a-zA-Z0-9]/     // Any alphanumeric (same as /\w/)
/[^0-9]/          // NOT a digit (negation with ^ inside [])
/[^aeiou]/        // Not a vowel

// Shorthand classes (use these!):
/\d/    // Digit: [0-9]
/\D/    // Non-digit: [^0-9]
/\w/    // Word char: [a-zA-Z0-9_]
/\W/    // Non-word char: [^\w]
/\s/    // Whitespace: [ \t\r\n\f\v]
/\S/    // Non-whitespace: [^\s]

// Examples:
/\d{3}-\d{4}/     // Phone-like: "555-1234"
/[A-Z][a-z]+/      // Capitalized word: "Hello", "World"
/#[0-9a-fA-F]{6}/  // Hex color code: "#ff5500"

Quantifiers: How Many Times?

// Quantifiers apply to the PRECEDING element:
/a*/     // Zero or more a's ("" is valid match!)
/a+/     // One or more a's (at least one)
/a?/     // Zero or one a (optional)
/a{3}/   // Exactly 3 a's ("aaa")
/a{2,4}/ // 2 to 4 a's ("aa", "aaa", "aaaa")
/a{2,}/  // 2 or more a's (no upper limit)

// ⚠️ Greedy vs Lazy (CRITICAL concept!)
// GREEDY (default): Match as MUCH as possible
const html = '<div>first</div><div>second</div>';
html.match(/<div>.*<\/div>/);
// Matches: '<div>first</div><div>second</div>' (greedy eats everything!)

// LAZY: Match as LITTLE as possible (add ? after quantifier)
html.match(/<div>.*?<\/div>/);
// Matches: '<div>first</div>' (lazy stops at first opportunity)

// Real-world example: Extract content between quotes
const str = 'He said "hello" and she said "world"';
str.match(/"(.*?)"/g);  // ["\"hello\"", "\"world\""]
// Without lazy: would match from first " to last "

Anchors & Boundaries

// Anchors don't match characters — they match POSITIONS:
/^Hello/     // "Hello" at START of string only
/world$/     // "world" at END of string only
/^Hello world$/  // Exact full-string match

// Word boundaries (\b) — position between word char and non-word char:
/\bcat\b/    // Matches "cat" but NOT "catalog" or "scattered"
// Useful for whole-word search!

// Common patterns using anchors:
/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i  // Email validation
/^https?:\/\/[^\s]+$/i                        // URL detection
/^\d{4}-\d{2}-\d{2}$/                         // Date YYYY-MM-DD
/^[+-]?\d+(\.\d+)?$/                           // Integer or decimal number

Groups & Capturing

// Capturing groups (...) — extract parts of the match:
const date = '2024-06-11';
date.match(/(\d{4})-(\d{2})-(\d{2})/);
// Full match: "2024-06-11"
// Group 1 (year):  "2024"
// Group 2 (month): "06"
// Group 3 (day):   "11"

// Named capture groups (much more readable!):
const result = 'user@domain.com'.match(/(?<name>\w+)@(?<domain>\w+)\.(?<tld>\w+)/);
result.groups.name;     // "user"
result.groups.domain;   // "domain"
result.groups.tld;      // "com"

// Non-capturing group (?:...) — group without capturing:
/(?:https?:\/\/)?(www\.\w+\.\w+)/
// First group doesn't capture, second does

// Backreferences — refer to earlier captured group:
/(\w+) \1/            // Matches "word word" (repeated word!)
/<(\w+)>.*?<\/\1>/    // Matches <b>...</b> but NOT <b></i>

// Lookahead assertions (match based on what FOLLOWS):
/\d+(?= dollars)/      // Match numbers only if followed by " dollars"
// "I have 100 dollars" → matches "100"
// "I have 100 euros"   → no match

// Negative lookahead:
/\d+(?! dollars)/      // Match numbers NOT followed by " dollars"
// "I have 100 euros"   → matches "100"
// "I have 100 dollars" → no match

// Lookbehind (what PRECEDES):
/(?<=\$)\d+/           // Match digits preceded by $
// "Price: $99" → matches "99"
/(?<!\$)\d+/           // Match digits NOT preceded by $
// "Price: $99, qty 5" → matches "5" only

Practical Examples You'll Actually Use

// === Validation ===
function validateEmail(email) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
  // Simple but practical. Don't try RFC-compliant email regex!
}

function validatePassword(password) {
  return /^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*]).{12,}$/.test(password);
}

function validateURL(url) {
  try { new URL(url); return true; }
  catch { return false; } // URL constructor > regex for URLs!
}

// === Extraction & Transformation ===
// Extract all hashtags:
'Check out #JavaScript and #WebDev'.match(/#\w+/g);
// ["#JavaScript", "#WebDev"]

// Format phone number:
'5551234567'.replace(/(\d{3})(\d{3})(\d{4})/, '($1) $2-$3');
// "(555) 123-4567"

// CamelCase to snake_case:
'myVariableName'.replace(/[A-Z]/g, '_$&').toLowerCase();
// "my_variable_name"

// Truncate words to max length:
'this is a very long sentence that needs shortening'.replace(/\b(\w{1,8})\s?\b/g, '$1\n');
// Break into lines where words exceed 8 chars

// Remove duplicate lines:
text.split('\n').filter((line, i, arr) => arr.indexOf(line) === i).join('\n');

// Find unquoted strings (complex!):
// Match strings not surrounded by quotes:
/'[^']*'|"[^"]*"|(\b\w{3,}\b)/g  // Then filter out captured group 1

// === Search & Replace in Code ===
// Add console.log before each function line (for debugging):
code.replace(/^(function\s+\w+)/gm, 'console.log("$1"); $1');

// Convert require() to import:
code.replace(/const\s+(\w+)\s*=\s*require\(['"](.*)['"]\)/g, 'import $1 from "$2";');

// Remove console.log statements (before deploy):
code.replace(/^\s*console\.(log|debug|info)\(.*\);\s*$/gm, '');

Testing & Debugging Regex

// Test in browser console or Node.js:
const pattern = /your-regex-here/;
pattern.test('test string');   // true/false
'test string'.match(pattern);  // Array of matches or null
'test string'.replaceAll(pattern, 'replacement');

// Debugging tips:
// 1. Start simple, build up piece by piece
// 2. Use regex101.com or regexr.com for visual debugging
// 3. Use .source to see the actual pattern string:
console.log(pattern.source);

// 4. Break complex patterns into pieces:
const WORD = /[a-zA-Z]+/;
const SPACE = /\s+/;
const sentencePattern = new RegExp(`^${WORD.source}(${SPACE.source}${WORD.source})*$`);

// 5. Common gotchas:
// - In JS strings, backslashes must be escaped: new RegExp('\\d+') not new RegExp('\d+')
// - . doesn't match newline by default; use [\s\S] instead if needed
// - Always use ^ and $ anchors for full-string validation
// - test() returns true on partial match; use anchors for exact matching

What's your favorite regex trick? What regex problem has been haunting you?

Follow @armorbreak for more practical developer guides.