DEV Community: Mark Yu

Frontend Linear Data Structures Deep Dive: Arrays, Stacks, Queues, and Linked Lists

Mark Yu — Tue, 16 Jun 2026 19:23:49 +0000

The Big Picture

Before diving into stacks, queues, and linked lists, it helps to know where they sit in the landscape.

Linear structures - arrays, linked lists, stacks, queues - arrange elements one after another. Each node has exactly one predecessor and one successor.

Non-linear structures - trees and graphs - are a different story for another day.

Arrays

Arrays are the workhorse of JS. They use contiguous memory and give you direct access to any element by index - no traversal needed.

Adding Elements

push - appends to the end.

Simple enough, but there's a catch: arrays are initialized with a fixed capacity. When you exceed it, JS triggers a resize: allocate a bigger block, copy everything over, free the old space. It's not free.

Linked lists don't have this problem - they allocate memory per node, dynamically.

unshift - prepends to the beginning.

Every existing element has to shift right by one to make room. The longer the array, the worse the performance. Fine for small arrays; avoid it in hot paths.

splice - the Swiss Army knife.

array.splice(startIndex, deleteCount, ...itemsToAdd)

startIndex: where to begin
deleteCount: how many to remove (pass 0 to insert without deleting)
...itemsToAdd: optional elements to insert

Key things to know: splice mutates the original array and returns the deleted elements as a new array (empty array if nothing was deleted). Like all native array methods - push, pop, unshift, shift - it's not a pure function.

const arr = [1, 2];

arr.splice(1, 0, 3);   // insert 3 at index 1
console.log(arr);      // [1, 3, 2]

arr.splice(1, 1);      // delete element at index 1
console.log(arr);      // [1, 2]

Stack

A stack is LIFO - Last In, First Out. Think of it like a stack of plates: you can only add or remove from the top.

push → [bottom ... top] ← pop

In JS, implement with a plain array:

const stack = [];

stack.push('A');
stack.push('B');
stack.push('C');

while (stack.length) {
  console.log(stack.pop()); // C, B, A
}

push to add to the top
pop to remove from the top
Peek without removing: stack[stack.length - 1]

Queue

A queue is FIFO - First In, First Out. Like a checkout line: first in, first served.

push → [back ... front] → shift

const queue = [];

queue.push('Alice');
queue.push('Bob');
queue.push('Charlie');

while (queue.length) {
  console.log(queue.shift()); // Alice, Bob, Charlie
}

Heads up: shift has an O(n) cost - every element shifts left by one index after removal. For small arrays, no big deal. At scale, this becomes a bottleneck. If you're building a high-throughput queue, a linked list implementation is the right call.

Linked Lists

Why Not Just Use Arrays?

Arrays are great when you need fast random access. But inserting or deleting anywhere except the tail requires shifting elements - O(n) work.

Linked lists flip the tradeoff:

	Array	Linked List
Memory	Contiguous (if uniform types)	Scattered, node-by-node
Random access	O(1)	O(n) - must traverse
Insert/delete	O(n) at non-tail positions	O(1) once you have the node
Best for	Frequent reads, small data	Frequent writes, large data

Structure

Each node holds two things:

val: the data
next: a pointer to the next node (null if it's the tail)

In JS, a linked list is just nested objects:

{
  val: 1,
  next: {
    val: 2,
    next: null
  }
}

To access any element, you start at head and follow next pointers until you reach your target. There's no shortcut - no index to jump to directly.

Basic Implementation

function ListNode(val) {
  this.val = val;
  this.next = null;
}

const head = new ListNode(1);
head.next = new ListNode(2);
// 1 -> 2 -> null

Insert

Find the predecessor node, point its next to the new node, then point the new node's next to the original successor. No data movement, just pointer reassignment - O(1).

Delete

Find the predecessor, skip the target by pointing next directly to the target's successor. Done - O(1).

The expensive part with linked lists isn't insert/delete - it's finding the right node, which always costs O(n).

Two JS Gotchas Worth Knowing

Array Memory Isn't Always Contiguous

JS engines optimize for uniform-type arrays. Mix types and the engine may fall back to a hash map structure internally, losing the contiguous memory layout.

const fast = [1, 2, 3, 4];           // likely contiguous
const slower = ['a', 1, { b: 2 }];   // likely hash map internally

Don't mix types in performance-sensitive arrays.

`sort()` Sorts Strings by Default

[10, 2, 5].sort()                    // [10, 2, 5] - ASCII order, wrong
[10, 2, 5].sort((a, b) => a - b)     // [2, 5, 10] - correct

Always pass a comparator when sorting numbers.

Quick Reference

Structure	Add	Remove	Access	Rule
Array	`push` O(1)*	`pop` O(1)	O(1) by index	-
Stack	`push`	`pop`	O(n)	LIFO
Queue	`push`	`shift` O(n)	O(n)	FIFO
Linked List	O(1) once positioned	O(1) once positioned	O(n) traversal	-

*Amortized - occasional resize at O(n)

Common Pitfalls

unshift is slow at scale - it shifts every element. Use sparingly.
Array-based queues degrade - shift is O(n). For high volume, use a linked list.
All native array methods mutate - push, pop, shift, unshift, splice all modify in place. None are pure functions.
Don't mix array element types - you lose the contiguous memory advantage.
Stacks and queues aren't separate data structures - they're arrays (or linked lists) with constrained access rules.
Linked list insert/delete is fast; finding the node isn't - the O(n) cost is in traversal, not the operation itself.

JS Sorting Algorithms Every Developer Should Know

Mark Yu — Tue, 16 Jun 2026 19:10:01 +0000

You call .sort() every day without thinking about it. But the sorting algorithm your language's standard library actually uses is a carefully engineered hybrid - and understanding what it's doing (and why) makes you a better engineer. Not just for interviews. For writing better code, debugging weird performance cliffs, and knowing when to reach for something different.

This post covers the eight classic sorting algorithms - the ones that appear in every CS curriculum and show up in every whiteboard interview - with an honest take on what they're actually useful for in 2025.

The two camps

Every classic sorting algorithm falls into one of two buckets:

	Time complexity	Examples
Brute force	O(n²) average	Bubble, Selection, Insertion
Divide & conquer	O(n log n) average	Merge, Quick, Heap

O(n²) sounds terrible, and at scale it is. But for arrays under ~50 elements, the constant factors often make the "slow" algorithms faster in practice - which is why Timsort (Python, JavaScript) and Introsort (C++) use insertion sort internally for small subarrays.

The other axis that matters: stable vs unstable. A stable sort preserves the relative order of equal elements. If you're sorting records by last name and want a secondary sort by first name to be preserved, you need stability. Quicksort is unstable. Merge sort is stable. This matters.

1. Bubble Sort - the one everyone knows, no one uses

How it works: Compare adjacent elements, swap if out of order. Repeat until no swaps happen.

def bubble_sort(arr):
    n = len(arr)
    for i in range(n):
        for j in range(0, n - i - 1):
            if arr[j] > arr[j + 1]:
                arr[j], arr[j + 1] = arr[j + 1], arr[j]
    return arr

Complexity: O(n²) average and worst case, O(n) best case (already sorted)\
Stable: Yes\
Space: O(1)

Honest take: Bubble sort is for teaching, not production. The only place it wins is a nearly-sorted array where you add an early-exit optimization - it becomes O(n) on already-sorted data. But insertion sort does the same thing better.

That said: every CS interview will assume you know it. You should know it.

2. Selection Sort - simpler, not better

How it works: Find the minimum element in the unsorted portion, swap it to the front. Repeat.

def selection_sort(arr):
    for i in range(len(arr)):
        min_idx = i
        for j in range(i + 1, len(arr)):
            if arr[j] < arr[min_idx]:
                min_idx = j
        arr[i], arr[min_idx] = arr[min_idx], arr[i]
    return arr

Complexity: O(n²) in all cases - it always does the full scan\
Stable: No (standard implementation)\
Space: O(1)

Honest take: Selection sort makes fewer swaps than bubble sort - exactly n-1 swaps always - which matters if swapping is expensive (say, moving large records on disk). Otherwise it has no advantage. It's also not stable, which rules it out for anything that cares about order preservation.

3. Insertion Sort - the underrated one

How it works: Build a sorted subarray from left to right, inserting each new element into its correct position.

def insertion_sort(arr):
    for i in range(1, len(arr)):
        key = arr[i]
        j = i - 1
        while j >= 0 and arr[j] > key:
            arr[j + 1] = arr[j]
            j -= 1
        arr[j + 1] = key
    return arr

Complexity: O(n²) worst case, O(n) best case (sorted data), O(nk) if each element is at most k positions from its sorted position\
Stable: Yes\
Space: O(1)

Honest take: This is the one people underestimate. Insertion sort is adaptive - it runs in O(n) on nearly-sorted data. It's also online, meaning it can sort a stream of data as it arrives. And it's the algorithm that Timsort (used by Python and JavaScript under the hood) falls back to for subarrays under 64 elements, because cache performance and constant factors make it beat merge sort at small sizes.

If you ever need to sort a small array yourself: use insertion sort.

4. Shell Sort - insertion sort, but turbocharged

How it works: Generalization of insertion sort. Instead of comparing adjacent elements, compare elements h positions apart. Decreasing h toward 1.

def shell_sort(arr):
    n = len(arr)
    gap = n // 2
    while gap > 0:
        for i in range(gap, n):
            temp = arr[i]
            j = i
            while j >= gap and arr[j - gap] > temp:
                arr[j] = arr[j - gap]
                j -= gap
            arr[j] = temp
        gap //= 2
    return arr

Complexity: O(n log² n) with good gap sequences, though the exact bound depends heavily on the gap sequence used\
Stable: No\
Space: O(1)

Honest take: Shell sort is an interesting middle ground - better than insertion sort on large arrays, no extra memory needed, but it's been largely superseded by introsort and Timsort. Still worth knowing because the gap-sequence idea is non-obvious and comes up in other places (like some cache-oblivious algorithms).

5. Merge Sort - the stable workhorse

How it works: Divide the array in half, recursively sort both halves, then merge them back.

def merge_sort(arr):
    if len(arr) <= 1:
        return arr
    mid = len(arr) // 2
    left = merge_sort(arr[:mid])
    right = merge_sort(arr[mid:])
    return merge(left, right)

def merge(left, right):
    result = []
    i = j = 0
    while i < len(left) and j < len(right):
        if left[i] <= right[j]:
            result.append(left[i])
            i += 1
        else:
            result.append(right[j])
            j += 1
    result.extend(left[i:])
    result.extend(right[j:])
    return result

Complexity: O(n log n) in all cases - guaranteed, no worst case\
Stable: Yes\
Space: O(n) - this is the catch

Honest take: Merge sort has guaranteed O(n log n) performance - unlike quicksort which can degrade to O(n²) on bad pivot choices. It's also stable. Those two properties make it the go-to for sorting linked lists, external sorting (data that doesn't fit in memory), and anywhere stability matters.

The downside is memory: it needs O(n) extra space. For large arrays in memory-constrained environments, that's a real cost.

Java uses a variant of merge sort (Timsort) for object arrays. The stable guarantee matters when you're chaining comparators.

6. Quick Sort - the fast one (usually)

How it works: Pick a pivot, partition the array so everything smaller is to the left and everything larger is to the right, then recursively sort both sides.

def quick_sort(arr, low=0, high=None):
    if high is None:
        high = len(arr) - 1
    if low < high:
        pivot_idx = partition(arr, low, high)
        quick_sort(arr, low, pivot_idx - 1)
        quick_sort(arr, pivot_idx + 1, high)
    return arr

def partition(arr, low, high):
    pivot = arr[high]
    i = low - 1
    for j in range(low, high):
        if arr[j] <= pivot:
            i += 1
            arr[i], arr[j] = arr[j], arr[i]
    arr[i + 1], arr[high] = arr[high], arr[i + 1]
    return i + 1

Complexity: O(n log n) average, O(n²) worst case (sorted input with bad pivot selection)\
Stable: No\
Space: O(log n) average stack space

Honest take: Quicksort has the best average-case performance of any comparison sort in practice - the constant factors are small because it has great cache behavior and does comparisons in-place. That's why C's qsort and many other standard libraries are named after it.

The catch: it degrades to O(n²) on sorted or nearly-sorted input with naive pivot selection. Modern implementations use randomized pivots, median-of-three, or switch strategies entirely - which is how introsort was born.

Quicksort is fast. But never trust it on user-provided data without randomized pivots unless you want to be in a CVE.

7. Heap Sort - the Linux kernel's pick

How it works: Build a max-heap from the array, then repeatedly extract the max element to build the sorted array.

def heap_sort(arr):
    n = len(arr)
    # Build max heap
    for i in range(n // 2 - 1, -1, -1):
        heapify(arr, n, i)
    # Extract elements
    for i in range(n - 1, 0, -1):
        arr[0], arr[i] = arr[i], arr[0]
        heapify(arr, i, 0)
    return arr

def heapify(arr, n, i):
    largest = i
    left, right = 2 * i + 1, 2 * i + 2
    if left < n and arr[left] > arr[largest]:
        largest = left
    if right < n and arr[right] > arr[largest]:
        largest = right
    if largest != i:
        arr[i], arr[largest] = arr[largest], arr[i]
        heapify(arr, n, largest)

Complexity: O(n log n) in all cases - including worst case\
Stable: No\
Space: O(1) - sorts in place

Honest take: Heap sort has the best worst-case guarantee among the in-place sorts: O(n log n) always, O(1) space. The Linux kernel uses it instead of quicksort for exactly this reason - when you can't tolerate O(n²) worst-case behavior, heapsort is the safe choice.

The downside: poor cache performance. Heap sort jumps around memory in a way that causes a lot of cache misses, which makes it slower in practice than quicksort or merge sort even though it has the same asymptotic complexity. You'll rarely use it directly, but knowing it exists and why is useful.

8. Radix Sort - breaking the comparison barrier

How it works: Sort integers digit by digit, from least significant to most significant, using a stable sort (usually counting sort) at each pass.

def radix_sort(arr):
    max_val = max(arr)
    exp = 1
    while max_val // exp > 0:
        counting_sort_by_digit(arr, exp)
        exp *= 10
    return arr

def counting_sort_by_digit(arr, exp):
    n = len(arr)
    output = [0] * n
    count = [0] * 10
    for i in range(n):
        index = (arr[i] // exp) % 10
        count[index] += 1
    for i in range(1, 10):
        count[i] += count[i - 1]
    for i in range(n - 1, -1, -1):
        index = (arr[i] // exp) % 10
        output[count[index] - 1] = arr[i]
        count[index] -= 1
    for i in range(n):
        arr[i] = output[i]

Complexity: O(nk) where k is the number of digits - effectively O(n) for fixed-width integers\
Stable: Yes\
Space: O(n + k)

Honest take: Radix sort is the algorithm that breaks the O(n log n) lower bound - because it doesn't use comparisons. It works on the actual digit/bit structure of the data. For sorting large sets of integers, IP addresses, phone numbers, or any fixed-length data, radix sort can be dramatically faster than comparison sorts.

The catch: it only works on integers or things that can be mapped to integers (strings of fixed length, dates). It doesn't work on arbitrary comparable data. And the constant factors mean that for small arrays, comparison sorts win.

What `.sort()` is actually doing

Here's the part that makes the above useful beyond theory:

Language	Algorithm used	Notes
Python	Timsort	Merge sort + insertion sort hybrid. Stable. Since Python 2.3.
JavaScript (V8)	Timsort	Same algorithm, switched from quicksort in 2019 for spec compliance (stable sort required by ES2019+).
Java (objects)	Timsort	`Arrays.sort(Object[])` and `Collections.sort()`.
Java (primitives)	Dual-pivot quicksort	`Arrays.sort(int[])`. No stability needed, faster in practice.
C++ STL	Introsort	Quicksort + heapsort fallback + insertion sort for small arrays. Unstable.
Linux kernel	Heapsort	Chosen for guaranteed worst-case and no stack space.
Swift	Timsort

Timsort is worth understanding at a high level: it looks for already-sorted "runs" in the input, then merges them with merge sort. Real-world data is often partially sorted (think: appending to a sorted list, or data with timestamps). Timsort exploits this and can run in O(n) on such data, beating theoretical alternatives.

Quick reference

Algorithm	Best	Average	Worst	Space	Stable
Bubble	O(n)	O(n²)	O(n²)	O(1)	Yes
Selection	O(n²)	O(n²)	O(n²)	O(1)	No
Insertion	O(n)	O(n²)	O(n²)	O(1)	Yes
Shell	O(n log n)	O(n log² n)	O(n²)	O(1)	No
Merge	O(n log n)	O(n log n)	O(n log n)	O(n)	Yes
Quick	O(n log n)	O(n log n)	O(n²)	O(log n)	No
Heap	O(n log n)	O(n log n)	O(n log n)	O(1)	No
Radix	O(nk)	O(nk)	O(nk)	O(n+k)	Yes

When do you actually implement one yourself?

Honestly? Almost never. But here's when the knowledge matters:

You need a stable sort in a language that doesn't guarantee one: Some older runtimes, embedded environments, or custom data structures. Reach for merge sort.

You're sorting a small array in a hot loop: Array.sort() has overhead from being general-purpose. For arrays under ~20 elements in a performance-critical path, inline insertion sort is faster.

You need guaranteed worst-case bounds and can't use O(n) space: Heapsort.

You're sorting integers and n is large: Radix sort. The O(n) vs O(n log n) difference shows up fast at a million+ items.

You're writing something that needs to handle adversarial input: Randomize your quicksort pivots. Or use merge sort. A sorted-input DoS via quicksort is a real vulnerability class.

The mental model to take away: the "best" sorting algorithm doesn't exist - it depends on the constraints. Timsort is the best general-purpose answer for unknown data. Quicksort is fastest when you know the data is random. Merge sort wins when you need stability and memory isn't a constraint. Heapsort wins when you need worst-case guarantees in O(1) space. Radix sort wins when you're sorting integers at scale.

Knowing which to reach for, and why, is the whole point of learning them.

React 19 Micro-Interactions Without Layout Jank

Mark Yu — Thu, 04 Jun 2026 03:31:22 +0000

Micro-interactions are easy to overdo.

The good ones make the UI feel responsive. The bad ones delay the user, shift layout, or turn every click into a tiny fireworks show.

My rule is simple:

Animate feedback, not uncertainty.

Start With the Cheapest Interaction

For a button, CSS is enough:

export function SaveButton({ saving }) {
  return (
    <button className="save-button" disabled={saving}>
      {saving ? "Saving..." : "Save changes"}
    </button>
  );
}

.save-button {
  transform: translateY(0);
  transition:
    transform 140ms ease,
    background-color 140ms ease,
    box-shadow 140ms ease;
}

.save-button:hover {
  transform: translateY(-1px);
}

.save-button:active {
  transform: translateY(0);
}

No layout properties. No JavaScript animation. No drama.

Avoid Animating Layout

Prefer:

transform
opacity
color
shadow, carefully

Be careful with:

height
width
top
left
margin

Those can trigger layout work and make the UI feel janky.

Optimistic Feedback

For React apps, many interactions feel better when the UI responds before the server round trip finishes.

function LikeButton({ initialLiked }) {
  const [liked, setLiked] = useState(initialLiked);
  const [pending, setPending] = useState(false);

  async function toggle() {
    const next = !liked;
    setLiked(next);
    setPending(true);

    try {
      await fetch("/api/like", {
        method: "POST",
        body: JSON.stringify({ liked: next }),
      });
    } catch {
      setLiked(!next);
    } finally {
      setPending(false);
    }
  }

  return (
    <button className={liked ? "liked" : ""} onClick={toggle} disabled={pending}>
      {liked ? "Liked" : "Like"}
    </button>
  );
}

The important part is rollback. Optimistic UI without rollback is just lying with confidence.

Respect Reduced Motion

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

I usually scope this more carefully in production, but the principle matters: motion should not be forced.

My Interaction Checklist

Question	If no
Does it communicate state?	remove it
Does it keep layout stable?	redesign it
Does it work with keyboard?	fix focus state
Does it respect reduced motion?	add fallback
Does it still feel fast on low-end devices?	simplify

React 19 Angle

React 19 makes async UI patterns cleaner, but it does not automatically make motion good.

Use React for state and transitions. Use CSS for simple visual feedback. Reach for animation libraries only when the interaction is complex enough to justify them.

Final Thought

Premium UI is not about more animation. It is about the interface responding at the exact moment the user expects it to.

Which micro-interaction in a product made the UI feel genuinely better to you?

Free 3D Asset Sites I’d Actually Use in a WebGL Project

Mark Yu — Thu, 04 Jun 2026 02:05:21 +0000

Free 3D assets are great until one of them adds 40MB to your landing page.

That is the part many asset lists skip. The source matters, but the workflow after download matters more.

My filter is simple:

license clear?
format usable?
polycount reasonable?
textures optimized?
attribution saved?

If any answer is unclear, I do not put it into a production project.

Sites Worth Checking

Site	Best for	Watch out
Poly Haven	HDRIs, textures, models	large texture files
Sketchfab	broad model variety	license varies per asset
Kenney	game-ready low-poly assets	style may be specific
Quaternius	low-poly characters/props	attribution/license check
ambientCG	PBR textures	optimize resolution
OpenGameArt	game assets	quality varies a lot
BlenderKit	Blender workflow	account/license details
CGTrader Free	realistic models	cleanup often needed
TurboSquid Free	mixed models	formats vary
Itch.io asset packs	indie game style	read pack license
Smithsonian 3D	historical scans	not always game-ready

My Import Workflow

I do not drop assets straight into a Three.js scene anymore.

I do this first:

Open in Blender.
Remove unused meshes/materials.
Apply scale/rotation.
Reduce texture size if needed.
Export as .glb.
Compress with gltf-transform.

Example:

npx gltf-transform inspect model.glb
npx gltf-transform optimize model.glb model.optimized.glb

This often cuts the file size dramatically.

License Notes Are Not Optional

Create a small file:

assets/licenses.md

Track:

Asset: wooden-crate.glb
Source: Poly Haven
Author: ...
License: CC0
Downloaded: 2026-06-16
Changes: resized textures, exported GLB

This feels tedious until you need to publish, sell, or open-source the project.

WebGL Performance Check

Before shipping:

keep GLB files small
compress textures
avoid unnecessary 4K maps
merge meshes where practical
lazy-load heavy models
test on a low-end laptop or phone

The best free asset is still bad if it tanks your frame rate.

Final Thought

Free assets can make a prototype feel real fast. Just do the boring cleanup work before production.

What free 3D asset site has saved one of your projects?

Next.js Images Without CLS: My LQIP Blur-Up Setup

Mark Yu — Thu, 04 Jun 2026 01:52:51 +0000

Image layout shift is one of those bugs that makes a page feel cheap.

The content loads, the image arrives late, the text jumps, and the user loses their place.

In Next.js, the fix is not complicated: give the browser stable dimensions and use a placeholder only as polish, not as a layout crutch.

The Rule

No known image box -> layout shift risk
Known width/height -> stable layout
Blur placeholder -> nicer loading

Local Image Example

import Image from "next/image";
import hero from "@/public/hero.jpg";

export default function Hero() {
  return (
    <Image
      src={hero}
      alt="Dashboard showing image performance metrics"
      priority
      placeholder="blur"
      sizes="100vw"
      className="heroImage"
    />
  );
}

For static imports, Next.js can infer dimensions and generate blur data.

That is the easiest path.

Remote Image Example

Remote images need explicit dimensions:

<Image
  src="https://example.com/product.jpg"
  alt="Product preview"
  width={1200}
  height={800}
  placeholder="blur"
  blurDataURL={blurDataUrl}
  sizes="(max-width: 768px) 100vw, 720px"
/>

If you do not know the dimensions, fetch or store them before render. Guessing is how CLS sneaks back in.

CSS Must Not Break the Ratio

.heroImage {
  width: 100%;
  height: auto;
  object-fit: cover;
  border-radius: 12px;
}

Avoid setting random height without thinking about aspect ratio.

Production Checklist

Check	Why
`width` and `height` set	prevents layout shift
meaningful `alt`	accessibility
`sizes` accurate	avoids oversized downloads
`priority` only for hero	avoids stealing bandwidth
blur placeholder small	avoids bloated HTML
remote domains configured	avoids runtime failures

My Take on LQIP

LQIP is not the main performance feature. It is a perceived performance feature.

The real layout fix is reserving the image box.

Blur-up makes the wait feel smoother, but it will not save a layout that does not know its own dimensions.

Final Thought

Zero CLS images are mostly discipline: dimensions, ratios, correct sizes, and not treating placeholders as magic.

What image bug has caused the most layout pain in your Next.js projects?

Bad Data Quality Costs More Than a Slow Query

Mark Yu — Wed, 16 Oct 2024 02:19:45 +0000

Bad data usually does not explode.

It quietly poisons reports, recommendations, billing, search, and AI features until nobody trusts the system.

That loss of trust is expensive.

What Bad Data Looks Like

Not all bad data is obviously broken.

Problem	Example
Missing value	`email = null` for active users
Invalid format	phone number stored three different ways
Duplicate entity	same customer created twice
Stale value	subscription says active after cancellation
Conflicting source	CRM and billing disagree
Schema drift	event payload changes without warning

The worst bugs are the ones that still produce a dashboard.

Add Validation at the Boundary

Do not let obviously invalid data enter the system.

import { z } from "zod";

const SignupSchema = z.object({
  email: z.string().email(),
  plan: z.enum(["free", "pro", "team"]),
});

const input = SignupSchema.parse(request.body);

This is cheaper than cleaning the warehouse later.

Add Constraints in the Database

App validation is not enough.

ALTER TABLE users
ADD CONSTRAINT users_email_unique UNIQUE (email);

ALTER TABLE subscriptions
ADD CONSTRAINT subscriptions_status_check
CHECK (status IN ('trial', 'active', 'canceled'));

The database should reject impossible states.

Track Data Quality Like Production Health

Useful checks:

SELECT COUNT(*) FROM users WHERE email IS NULL;

SELECT email, COUNT(*)
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

SELECT COUNT(*)
FROM subscriptions
WHERE status = 'active'
  AND canceled_at IS NOT NULL;

These are not glamorous, but they catch real problems.

Ownership Matters

Every important field needs an owner.

If nobody owns customer_status, nobody knows whether billing, CRM, support, or the product database is allowed to change it.

Visual map:

source system -> validation -> database -> event/log -> analytics

If quality breaks at the source, downstream tools only make the wrong answer prettier.

Why This Matters More With AI

AI agents and retrieval systems make bad data more visible.

If your internal docs, tickets, metrics, and customer records are messy, an AI assistant will confidently retrieve messy context.

In 2026, data quality is not just a BI problem. It is also an AI reliability problem.

Final Thought

Poor data quality is engineering debt with a business disguise.

Fix it close to where the data enters the system, give fields clear ownership, and monitor quality like you monitor latency.

What data quality issue created the most confusion in one of your projects?

Network Address Calculation: The Subnet Math That Matters

Mark Yu — Wed, 16 Oct 2024 02:09:35 +0000

Subnet math feels annoying until you need to debug a firewall rule, Kubernetes network policy, VPN route, or cloud security group.

Then suddenly this question matters:

Given an IP address and subnet mask, what network is it actually in?

Let’s calculate it directly.

The Rule

network address = IP address AND subnet mask

That is it.

The AND operation compares bits:

IP bit	Mask bit	Result
0	0	0
0	1	0
1	0	0
1	1	1

Example: 192.168.10.37/24

/24 means the subnet mask is:

255.255.255.0

IP:

192.168.10.37

Mask:

255.255.255.0

Network:

192.168.10.0

With /24, the first three octets are the network part. The last octet is host space.

Example: 192.168.10.37/26

/26 is more interesting.

Mask:

255.255.255.192

The last octet in binary:

IP:   37  = 00100101
Mask: 192 = 11000000
AND:       00000000

So the network address is:

192.168.10.0/26

The /26 networks in the last octet move in blocks of 64:

Network	Host range
192.168.10.0/26	.1 - .62
192.168.10.64/26	.65 - .126
192.168.10.128/26	.129 - .190
192.168.10.192/26	.193 - .254

37 falls into the first block.

Quick Mental Shortcut

For masks in the last octet:

block size = 256 - mask_octet

For /26:

256 - 192 = 64

So networks start at:

0, 64, 128, 192

Find the block that contains the IP.

Python Check

import ipaddress

ip = ipaddress.ip_interface("192.168.10.37/26")
print(ip.network)

Output:

192.168.10.0/26

This is what I use when I do not want to trust my tired brain during network debugging.

Why Developers Should Care

Subnet mistakes show up in:

cloud VPC rules
Docker/Kubernetes networking
VPN routing
database allowlists
office network debugging
zero-trust access rules

One wrong CIDR can expose too much or block the service you need.

Final Thought

Subnetting is not glamorous, but it is one of those fundamentals that saves time when production networking gets weird.

What subnet or CIDR mistake has bitten you before?

Java BeanUtils Copying: Convenient, but Not Free

Mark Yu — Sun, 26 May 2024 11:06:48 +0000

Bean copying looks harmless until it hides a production bug.

I have used BeanUtils.copyProperties() for DTO conversion because it is fast to write. Then later someone adds a nested object, a field name changes, or performance matters, and the convenient helper suddenly becomes a quiet source of confusion.

So here is the practical rule:

Use BeanUtils for simple, boring object copying. Do not use it as your default domain mapping strategy.

The Basic Copy

With Apache Commons BeanUtils:

import org.apache.commons.beanutils.BeanUtils;

public class CopyDemo {
    public static void main(String[] args) throws Exception {
        UserEntity entity = new UserEntity("Mark", 30);
        UserDTO dto = new UserDTO();

        BeanUtils.copyProperties(dto, entity);

        System.out.println(dto);
    }
}

That is the reason people like it. One line replaces a bunch of setters.

But the hidden question is:

What exactly did it copy?

Shallow Copy Is the First Trap

If the object contains nested objects, BeanUtils copies the reference. It does not magically deep-copy your object graph.

class UserEntity {
    private String name;
    private Address address;
}

class UserDTO {
    private String name;
    private Address address;
}

After copying, both objects can point at the same Address.

That may be fine. It may also be a bug if one layer mutates the nested object.

Visual map:

UserEntity.address ----+
                       +----> same Address object
UserDTO.address -------+

If you need independent nested objects, write that mapping explicitly or use a mapper designed for it.

Reflection Has a Cost

BeanUtils usually relies on reflection and runtime property inspection.

That means:

less compile-time safety
slower mapping than direct code
mistakes may show up later
refactoring fields can be riskier

For one admin endpoint, who cares.

For mapping thousands of rows in a hot path, I would care.

Spring BeanUtils vs Apache BeanUtils

The method names look similar, but behavior differs.

Tool	Good for	Watch out
Spring `BeanUtils`	simple same-name copy	limited conversion
Apache `BeanUtils`	string conversion and dynamic property access	reflection overhead
MapStruct	production DTO mapping	setup and annotations
Manual mapping	critical domain logic	more code

My current preference:

quick internal tools: BeanUtils
API DTO mapping: MapStruct or manual mapping
sensitive business logic: manual mapping

A Safer DTO Mapping Example

Sometimes boring explicit code is better:

public UserDTO toDto(UserEntity entity) {
    UserDTO dto = new UserDTO();
    dto.setName(entity.getName());
    dto.setAge(entity.getAge());

    if (entity.getAddress() != null) {
        AddressDTO address = new AddressDTO();
        address.setCity(entity.getAddress().getCity());
        address.setCountry(entity.getAddress().getCountry());
        dto.setAddress(address);
    }

    return dto;
}

Yes, it is longer.

But during a code review, nobody has to guess what happens to address.

Where BeanUtils Still Makes Sense

I would still use it for:

small admin tools
test fixtures
simple JavaBean-to-JavaBean copying
prototypes
non-critical internal scripts

I would avoid it for:

hot paths
payment/order domain mapping
complex nested DTOs
security-sensitive field filtering
APIs where fields change often

Production Pitfall: Copying Too Much

This bug is easy to miss:

BeanUtils.copyProperties(userEntity, requestDto);

If requestDto contains fields like role, status, or createdAt, you may accidentally let user input overwrite fields it should not control.

For request-to-entity updates, I prefer explicit allow-list mapping:

user.setDisplayName(request.getDisplayName());
user.setBio(request.getBio());

It is less clever. It is safer.

Final Thought

BeanUtils is a convenience tool, not an architecture.

Use it where the mapping is boring. When the mapping carries business meaning, write it so the next developer can see every decision.

Have you ever had a DTO copy bug caused by a field you did not mean to map?

RedisJSON Is Useful When You Update Parts of a Document

Mark Yu — Fri, 24 May 2024 13:41:34 +0000

I would not use RedisJSON just because my payload happens to be JSON.

I would use it when I need fast reads and updates against parts of a document without fetching the whole blob, changing it in app code, and writing it back.

Here is the problem.

{
  "id": "user:42",
  "name": "Mark",
  "plan": "free",
  "profile": {
    "city": "Toronto",
    "skills": ["React", "Java", "Redis"]
  },
  "usage": {
    "posts": 23,
    "revisions": 4
  }
}

If this lives as a plain string in Redis, changing usage.revisions means:

GET user:42
Parse JSON in the app
Modify one field
SET user:42 ...

That is boring code, and boring code becomes dangerous when two requests update different fields at the same time.

RedisJSON gives you path-level commands instead.

Run It Locally

Use Redis Stack if you want the quickest local setup:

docker run --name redis-stack -p 6379:6379 -p 8001:8001 redis/redis-stack:latest

Then connect:

redis-cli

Store a Document

JSON.SET user:42 $ '{
  "id": "user:42",
  "name": "Mark",
  "plan": "free",
  "profile": {
    "city": "Toronto",
    "skills": ["React", "Java", "Redis"]
  },
  "usage": {
    "posts": 23,
    "revisions": 4
  }
}'

Read the whole thing:

JSON.GET user:42

Read one field:

JSON.GET user:42 $.profile.city

That is the first real win. You can ask for the part you need.

Update One Field

Upgrade the user:

JSON.SET user:42 $.plan '"pro"'

Increment a counter:

JSON.NUMINCRBY user:42 $.usage.revisions 1

Append a skill:

JSON.ARRAPPEND user:42 $.profile.skills '"Three.js"'

Read it back:

JSON.GET user:42 $.plan $.usage $.profile.skills

This is where RedisJSON feels better than manual serialization. Your command says exactly what changed.

Use NX and XX Intentionally

When adding fields, be explicit.

Only set profile.website if it does not exist:

JSON.SET user:42 $.profile.website '"https://www.m4rkyu.com"' NX

Only update plan if it already exists:

JSON.SET user:42 $.plan '"team"' XX

I like this because it turns "oops, I accidentally created the wrong shape" into a failed command instead of silent data drift.

Delete a Field

JSON.DEL user:42 $.profile.website

Delete the whole document with regular Redis:

DEL user:42

When I Would Use RedisJSON

Good fits:

Session-like documents that change small fields often.
Feature flags or user settings with nested structure.
Product/catalog snapshots that need fast reads.
Cached API responses where you update selected paths.

Weak fits:

Long-term source-of-truth data with complex relational queries.
Analytics workloads.
Huge documents that grow without discipline.
Anything you need to join across many entities.

RedisJSON is not a relational database replacement. It is a sharp Redis tool for JSON-shaped data.

The Practical Rule

If your app always reads and writes the entire object, plain Redis strings are probably enough.

If your app frequently changes nested fields, increments values, appends to arrays, or reads selected paths, RedisJSON earns its place.

Command Cheat Sheet

JSON.SET user:42 $ '{"name":"Mark"}'
JSON.GET user:42 $
JSON.GET user:42 $.name
JSON.SET user:42 $.plan '"pro"'
JSON.NUMINCRBY user:42 $.usage.revisions 1
JSON.ARRAPPEND user:42 $.profile.skills '"Redis"'
JSON.DEL user:42 $.profile.website
JSON.TYPE user:42 $.profile.skills

That is enough to start. Add search/indexing later only when you have a real query that needs it.

Database Table Design Starts With the Queries You Need

Mark Yu — Fri, 24 May 2024 13:32:14 +0000

I do not like designing tables from nouns first.

I prefer starting from the queries the application must answer.

That sounds backwards, but it prevents a common mistake: a clean-looking schema that becomes awkward the moment the product needs filtering, reporting, or permissions.

Start With Access Patterns

Before creating tables, write the important questions:

Find a user's published posts.
List orders by account and status.
Show the latest 20 events for a device.
Check whether a user can access a project.

Then design tables that can answer those questions clearly.

Example:

CREATE TABLE posts (
  id BIGINT PRIMARY KEY,
  author_id BIGINT NOT NULL,
  title VARCHAR(200) NOT NULL,
  status VARCHAR(30) NOT NULL,
  published_at TIMESTAMP NULL,
  created_at TIMESTAMP NOT NULL
);

For this query:

SELECT id, title, published_at
FROM posts
WHERE author_id = ?
  AND status = 'published'
ORDER BY published_at DESC
LIMIT 20;

The index should match the access pattern:

CREATE INDEX idx_posts_author_status_published
ON posts (author_id, status, published_at DESC);

Use Constraints as Guardrails

If invalid data should never exist, do not rely only on app code.

ALTER TABLE posts
ADD CONSTRAINT chk_posts_status
CHECK (status IN ('draft', 'published', 'archived'));

Use:

NOT NULL
foreign keys where appropriate
unique constraints
check constraints
sensible default values

The database is allowed to protect itself.

Normalize Until It Hurts, Then Denormalize Carefully

Normalization prevents duplicated inconsistent data.

But production systems sometimes denormalize for read performance.

The important word is carefully.

Choice	Good for	Risk
normalized	correctness, updates	more joins
denormalized	faster reads	stale duplicated data

If you denormalize, decide how the duplicated value gets updated.

No answer means future bug.

Avoid Mystery Columns

Columns like this age badly:

extra TEXT
data JSON
flag1 BOOLEAN
type VARCHAR(255)

JSON columns are useful, but if every important field ends up inside data, you lose constraints, discoverability, and indexing clarity.

My rule:

If the application filters, sorts, joins, or validates a field often, consider making it a real column.

Timestamps Are Not Optional

Most production tables need:

created_at TIMESTAMP NOT NULL,
updated_at TIMESTAMP NOT NULL

Many also need:

deleted_at TIMESTAMP NULL

Soft delete is not free, though. Every query must remember to exclude deleted rows.

WHERE deleted_at IS NULL

If you add soft delete, make it a deliberate pattern.

Final Thought

Good table design is not about making a beautiful ER diagram. It is about making future queries, constraints, and debugging less painful.

What schema decision looked clean at first but became painful later?

Java final, finally, finalize: Three Bugs They Prevent

Mark Yu — Fri, 24 May 2024 13:15:51 +0000

final, finally, and finalize look like siblings.

They are not.

I have seen beginners mix them up because tutorials explain them as definitions. I think they make more sense if you connect each one to the bug it prevents.

Quick Map

Keyword / method	What it protects against
`final`	accidental reassignment, override, or inheritance
`finally`	cleanup code being skipped
`finalize`	mostly historical cleanup confusion

The uncomfortable truth: you should understand finalize, but you probably should not use it.

`final`: Stop Accidental Change

Use final when a value or behavior should not be changed after it is set.

public class RateLimiter {
    private final int maxRequests;

    public RateLimiter(int maxRequests) {
        this.maxRequests = maxRequests;
    }

    public boolean allow(int currentRequests) {
        return currentRequests < maxRequests;
    }
}

Here maxRequests cannot be reassigned after construction. That is boring, and boring is good.

You can also use final on methods:

class BaseService {
    public final void audit() {
        System.out.println("audit event written");
    }
}

A subclass cannot override audit(). I would use this sparingly. If you need final everywhere, your inheritance design may already be too clever.

And on classes:

public final class StringUtils {
    private StringUtils() {}
}

This says: do not extend this class.

`finally`: Cleanup Even When Things Break

finally runs whether the try block succeeds or throws.

Old-style file handling:

FileReader reader = null;

try {
    reader = new FileReader("config.txt");
    // read file
} catch (IOException e) {
    System.out.println("read failed: " + e.getMessage());
} finally {
    if (reader != null) {
        try {
            reader.close();
        } catch (IOException ignored) {
            // logging would be better in production
        }
    }
}

This works, but modern Java gives you a cleaner option:

try (FileReader reader = new FileReader("config.txt")) {
    // read file
} catch (IOException e) {
    System.out.println("read failed: " + e.getMessage());
}

That is try-with-resources. In most production code, I would prefer it over a manual finally.

Still, finally matters when cleanup is not an AutoCloseable resource:

lock.lock();
try {
    updateSharedState();
} finally {
    lock.unlock();
}

This is the real bug finally prevents: a lock stays locked because an exception jumped over your cleanup line.

`finalize`: Know It, Then Avoid It

finalize() was intended to run before garbage collection reclaims an object.

@Override
protected void finalize() throws Throwable {
    System.out.println("cleanup before GC");
}

Do not build production cleanup around this.

Why?

You do not control when GC runs.
It may run much later than expected.
It adds performance and reliability problems.
It has been deprecated for removal in modern Java.

If you need cleanup, use AutoCloseable:

class ConnectionHandle implements AutoCloseable {
    @Override
    public void close() {
        System.out.println("connection closed");
    }
}

try (ConnectionHandle handle = new ConnectionHandle()) {
    System.out.println("using connection");
}

This is explicit. You can reason about it. Production code likes that.

The Rule I Use

Use final to make intent harder to accidentally break.
Use finally when cleanup must happen even after exceptions.
Avoid finalize; use explicit cleanup instead.

Final Thought

These three names are confusing, but the responsibilities are not.

final is about preventing change. finally is about guaranteed cleanup. finalize is a legacy GC hook you should not lean on.

Which Java keyword confused you the most when you first learned backend development?

Java throw vs throws: The Exception Bug They Reveal

Mark Yu — Wed, 22 May 2024 15:46:32 +0000

throw and throws are easy to memorize and still easy to misuse.

The real difference is not grammar.

throw is the moment you raise an exception. throws is the method contract that warns callers an exception may escape.

The Short Version

Keyword	Where it appears	What it means
`throw`	inside method body	raise this exception now
`throws`	method signature	this method may pass this exception upward

`throw`: Fail Here

public User findUser(String id) {
    if (id == null || id.isBlank()) {
        throw new IllegalArgumentException("User id is required");
    }

    return repository.findById(id);
}

This is a direct failure.

I like this for invalid programmer input or impossible states. Do not let bad data travel deeper into the system.

`throws`: Caller Must Deal With It

public String readConfig(String path) throws IOException {
    return Files.readString(Path.of(path));
}

The method is saying:

I might fail with IOException, and I am not handling it here.

Caller:

try {
    String config = readConfig("app.yml");
} catch (IOException e) {
    log.error("Failed to read config", e);
}

Checked vs Runtime Exceptions

Checked exceptions must be handled or declared:

public void load() throws IOException {
    Files.readString(Path.of("app.yml"));
}

Runtime exceptions do not need throws:

throw new IllegalArgumentException("Bad request");

My rough rule:

Use checked exceptions when the caller can reasonably recover.
Use runtime exceptions for programming mistakes or invalid state.

Do Not Swallow Exceptions

This is the code smell:

try {
    sendEmail();
} catch (Exception e) {
    // ignore
}

If the email matters, ignoring the exception lies to the system.

At least log it or return a failure result:

try {
    sendEmail();
} catch (MailException e) {
    log.warn("Email send failed for user {}", userId, e);
}

API Boundary Example

Inside infrastructure code:

public User loadUser(String id) throws SQLException {
    // database call
}

At the service boundary, I usually translate it:

public User getUser(String id) {
    try {
        return userDao.loadUser(id);
    } catch (SQLException e) {
        throw new UserLookupException("Failed to load user " + id, e);
    }
}

This keeps SQL details from leaking everywhere.

Final Thought

throw is an action. throws is a warning label.

Good exception design is mostly about choosing where a failure should be handled and where it should be translated.

Do you prefer checked exceptions or runtime exceptions in Java service code?

DEV Community: Mark Yu

Frontend Linear Data Structures Deep Dive: Arrays, Stacks, Queues, and Linked Lists

The Big Picture

Arrays

Adding Elements

Stack

Queue

Linked Lists

Why Not Just Use Arrays?

Structure

Basic Implementation

Insert

Delete

Two JS Gotchas Worth Knowing

Array Memory Isn't Always Contiguous

sort() Sorts Strings by Default

Quick Reference

Common Pitfalls

JS Sorting Algorithms Every Developer Should Know

The two camps

1. Bubble Sort - the one everyone knows, no one uses

2. Selection Sort - simpler, not better

3. Insertion Sort - the underrated one

4. Shell Sort - insertion sort, but turbocharged

5. Merge Sort - the stable workhorse

6. Quick Sort - the fast one (usually)

7. Heap Sort - the Linux kernel's pick

8. Radix Sort - breaking the comparison barrier

What .sort() is actually doing

Quick reference

When do you actually implement one yourself?

React 19 Micro-Interactions Without Layout Jank

Start With the Cheapest Interaction

Avoid Animating Layout

Optimistic Feedback

Respect Reduced Motion

My Interaction Checklist

React 19 Angle

Final Thought

Free 3D Asset Sites I’d Actually Use in a WebGL Project

Sites Worth Checking

My Import Workflow

License Notes Are Not Optional

WebGL Performance Check

Final Thought

Next.js Images Without CLS: My LQIP Blur-Up Setup

The Rule

Local Image Example

Remote Image Example

CSS Must Not Break the Ratio

Production Checklist

My Take on LQIP

Final Thought

Bad Data Quality Costs More Than a Slow Query

What Bad Data Looks Like

Add Validation at the Boundary

Add Constraints in the Database

Track Data Quality Like Production Health

Ownership Matters

Why This Matters More With AI

Final Thought

Network Address Calculation: The Subnet Math That Matters

The Rule

Example: 192.168.10.37/24

Example: 192.168.10.37/26

Quick Mental Shortcut

Python Check

Why Developers Should Care

Final Thought

Java BeanUtils Copying: Convenient, but Not Free

The Basic Copy

Shallow Copy Is the First Trap

Reflection Has a Cost

Spring BeanUtils vs Apache BeanUtils

A Safer DTO Mapping Example

Where BeanUtils Still Makes Sense

Production Pitfall: Copying Too Much

Final Thought

RedisJSON Is Useful When You Update Parts of a Document

Run It Locally

`sort()` Sorts Strings by Default

What `.sort()` is actually doing

`final`: Stop Accidental Change

`finally`: Cleanup Even When Things Break

`finalize`: Know It, Then Avoid It

`throw`: Fail Here

`throws`: Caller Must Deal With It