DEV Community: zhihu wu

How to Read a Diff Like a Developer (and Catch Bugs Before They Merge)

zhihu wu — Wed, 19 Aug 2026 13:17:39 +0000

We all look at diffs every day — pull request reviews, git diff output, merge conflict resolutions. But most of us only skim for red and green lines. Learning to read a diff structurally turns code review from a chore into the cheapest bug-finding tool you have.

What a diff actually is

A diff is a line-by-line comparison between two versions of a file. The concept comes from the classic Unix diff utility, and it's the foundation of every version control system. Behind the scenes, tools compute the longest common subsequence (LCS) of the two texts: lines that appear in both versions in the same order are "unchanged", and everything else is either added or removed. Understanding this helps you see why a diff looks the way it does — a big block of red followed by a big block of green is usually one rewritten chunk, not a deletion plus an unrelated addition.

A practical reading order

Check the boundaries first. Where do the changed hunks start and end? A change touching the first few lines often shifts indentation or imports — two different concerns that Git shows as a single hunk.
Look for structural changes before logic. A changed function signature, an extra parameter, a renamed variable — these explain most "why did my code break?" moments.
Watch for whitespace-only noise. Trailing spaces, line endings, and re-indentation can bury a real change among hundreds of fake ones.
Read the removed lines carefully. The deleted line is usually where the bug actually was — it's often the line someone's logic still depends on.

When you don't have git history

Not every comparison involves Git. I regularly compare two API responses to debug a payload difference, two CSV dumps to find the row that changed, or a config file (nginx.conf, .env, Docker Compose) before and after an edit. For those quick checks, I use the CodeToolbox Diff Checker — paste two versions, and it highlights added lines in green and removed lines in red, with everything processed locally in your browser (nothing gets uploaded). It has saved me from exporting files and squinting at them side by side more times than I can count.

The takeaway

Diffs are the universal language of code change. The faster you can read one, the faster you can review a pull request, resolve a conflict, or spot the single line that broke the build.

JSON vs XML in 2026: Why JSON Won (and Where XML Still Matters)

zhihu wu — Sun, 16 Aug 2026 13:10:58 +0000

In the early 2000s, if you wanted two systems to talk to each other, XML was the answer. Today, JSON is the default for almost every web API. How did that happen, and does XML still have a place?

Why JSON won

JSON's biggest advantage is that it maps directly onto the data structures programming languages already use. An object is a dictionary, an array is a list, a string is a string. When your API client is JavaScript running in a browser, JSON isn't just convenient, it's native: JSON.parse() and JSON.stringify() are built in.

It's also much lighter. Compare a typical XML document with its JSON equivalent and the JSON version is often half the size, because there are no opening and closing tags repeated for every field. That means less bandwidth, faster parsing, and happier mobile users.

And it's genuinely human-readable in a way XML struggles to match. Compact JSON is still easy to skim; the equivalent XML is dominated by tag noise.

Where XML still matters

None of this means XML is dead. It remains the foundation of several ecosystems:

SVG is XML, so every icon you ship is technically XML.
SOAP-based enterprise APIs are still running inside banks, airlines, and government systems.
Office document formats (DOCX, XLSX) are zipped XML files.
Configuration files like Maven's pom.xml or Android layouts lean on XML's strictness.

XML's real strength is namespaces, schemas (XSD), and mixed content, where text is interleaved with child elements. JSON has no direct answer for those. If your document needs attributes and structured validation, XML is a legitimate choice.

The practical takeaway

For new APIs, choose JSON. It's simpler, faster, and the whole ecosystem, from OpenAPI to JSON Schema to every language's standard library, has converged on it. For documents with complex validation or long-term archival, XML still earns its keep.

One habit that saves me time daily: after generating API responses, I run them through a formatter to catch syntax errors before debugging code that isn't the problem. JSON Formatter is my go-to, it validates, pretty-prints, and works entirely in the browser, so nothing sensitive ever leaves my machine.

Base64 Data URIs: When They Help and When They Hurt

zhihu wu — Fri, 14 Aug 2026 13:14:38 +0000

If you've ever pasted a small image straight into your HTML, you've used a Base64 data URI: data:image/png;base64,iVBORw0KGgo.... The browser decodes it as if it were a file — no extra HTTP request, no separate asset to deploy. It's a genuinely useful trick, but it's also easy to overuse. Here's a practical breakdown of when data URIs help, when they hurt, and how to spot the difference.

The math that matters: +33%

Base64 encodes 3 bytes of input into 4 text characters. That means a data URI is always about 33% larger than the original file. A 300 KB PNG becomes a ~400 KB string sitting inline in your HTML. On a slow mobile connection, that's real bytes the browser has to download before it can render anything above the fold.

So the first rule is: the bigger the asset, the worse the trade-off. Data URIs are great for things measured in kilobytes — a 1 KB logo, a 2 KB SVG icon, a few emoji. They're terrible for hero images and product photos.

When data URIs genuinely help

Email signatures — the image is embedded in the message body, so it renders even when the recipient's mail client blocks remote images.
Small icons and SVG backgrounds — no extra round trip, and SVGs scale at any resolution.
Single-file demos and prototypes — one HTML file with everything inline is trivial to share, attach, or screenshot.
Offline contexts — anything embedded travels with the document.

When they hurt

Any image over ~10-20 KB — the 33% overhead plus the base64 decode cost rarely beats a regular request.
HTTP/2+ sites — modern browsers multiplex requests cheaply; one more small request is not the penalty it was in 2012.
Images reused on multiple pages — each page re-downloads the same encoded string. A cached file is fetched once.
Caching and CDNs — you can't give a data URI cache headers, vary it, or serve it from a CDN edge.

The quick check

Before inlining, ask: would this file survive as a separate request? If it's tiny, static, and page-specific — inline it. If it's large, shared, or likely to change — keep it as a real file.

💡 Tip: When you do need Base64 — for a data URI, a JWT payload, or an API response — a free online Base64 encoder/decoder makes it a two-second job: paste, encode, copy. No installs, and everything happens in the browser.

Password Entropy, Explained: Why Length Beats Complexity

zhihu wu — Tue, 11 Aug 2026 13:14:58 +0000

Some passwords look strong and aren't. Tr0ub4dor&3 has 11 characters, an uppercase letter, a digit, and a symbol — yet crackers love it. Meanwhile correct horse battery staple is 28 characters of lowercase words and is vastly harder to guess. The difference is entropy.

What is password entropy?

Entropy measures unpredictability, in bits. Every bit doubles the number of possible passwords an attacker must try. The formula is simple:

entropy = length × log₂(charset size)

Lowercase letters (26): 4.7 bits per character
+ Uppercase (52): 5.7 bits
+ Digits (62): 6.0 bits
+ Symbols (~95): 6.6 bits

The charset matters — but only a little. Going from lowercase-only to full symbols buys you under 2 extra bits per character. Adding one character to a lowercase-only password buys you 4.7 bits. That's the whole argument in one sentence: length beats complexity, roughly two and a half times over.

Let's do the math

Tr0ub4dor&3 (11 chars, 4 charsets): 11 × 6.6 ≈ 73 bits
correcthorsebatterystaple (25 chars, lowercase): 25 × 4.7 ≈ 118 bits

The lowercase passphrase has more than 2⁴⁵ times the combinations. This is why modern guidelines (NIST SP 800-63B included) emphasize length over forced complexity.

Practical takeaways

Use 16+ characters. At 16 random characters you're past 90 bits — beyond practical brute force.
Let a generator do the work. Humans pick Password1!; CSPRNGs don't.
Unique per site. A 100-bit password is worthless if it's reused.
Respect site limits. If a site caps length or bans symbols, longer lowercase-only is still strong — just don't shrink a good password to 8 characters.

I generate all my passwords with a local tool: the CodeToolbox Password Generator runs entirely in the browser via crypto.getRandomValues(), so nothing ever leaves my machine. No signup, no upload — just generate and drop the result into your password manager.

Length beats complexity. Always.

15-Year vs 30-Year Mortgage: Do the Math Before You Sign

zhihu wu — Sun, 09 Aug 2026 13:12:06 +0000

When developers talk about buying a home, the conversation always hits the same fork: 15-year or 30-year mortgage? The 30-year's pitch is a lower monthly payment. The 15-year's pitch is dramatically less interest. Both are true — but the gap is much bigger than most people expect, and it deserves real math instead of a gut feeling.

Run the numbers

Take a $250,000 loan at 6.5%:

30 years: about $1,580/month and roughly $318,900 in total interest
15 years: about $2,178/month and roughly $142,000 in total interest

The 15-year payment is ~$600/month higher, but it eliminates ~$177,000 in interest — more than half the interest bill. That's not pocket change; that's years of tuition, a serious head start on retirement, or a lot of freedom.

Why the gap is so wide

Amortized loans front-load interest. In year one of a 30-year mortgage at 6.5%, the vast majority of each payment is interest. Over three decades, interest keeps accruing on a large balance. A 15-year loan attacks both levers at once: fewer years of accrual and, typically, a lower rate.

The counterargument: opportunity cost

A 15-year term isn't automatically correct. The extra $600/month could go into index funds instead. If your expected investment returns comfortably beat your mortgage rate, the 30-year can win on paper — but only if you actually invest the difference. Most people don't, which is why the 15-year is effectively a forced-savings machine with a guaranteed 6.5% return.

A simple framework

Can you handle the 15-year payment without stretching? If yes, the interest savings usually win.
Would the difference actually be invested? If it would evaporate into spending, the 15-year wins by default.
What's the rate gap? 15-year rates run lower; a 0.5-1% difference makes the shorter term even more compelling.

Do the math on your own loan

Every loan is different — your rate, amount, and timeline change the answer. Whenever I'm comparing terms, I keep a free loan calculator open in a tab; it shows the monthly payment, total interest, and a full amortization schedule, so I can see exactly when the interest share of each payment drops below half. Five minutes with real numbers beats a year of opinions.

The 70% Rule: Finding the Sweet Spot for Web Image Compression

zhihu wu — Thu, 06 Aug 2026 13:11:27 +0000

When I audit page speed for a client, images are the culprit more often than JavaScript, fonts, or render-blocking CSS. A 2MB hero photo will undo months of performance work. But the fix isn't as simple as "compress everything to the max" — crank quality too low and you ship blurry images that make your site look broken.

Here's the mental model I use to get 60-80% file size savings without visible damage.

Quality follows a curve, not a line

The relationship between the JPEG/WebP quality slider and file size is nonlinear. Going from 100 to 90 barely shrinks anything, while 90 to 70 cuts files roughly in half. The visual difference between 90 and 70, meanwhile, is usually invisible on screen. Below 50, you hit the cliff: file size keeps dropping but artifacts (blocking, ringing around text) become obvious fast.

The 70% rule

As a starting point, compress at quality 70-80. It's the zone where most photos look identical to the original on any normal display but weigh a fraction of the source. Use 85 for hero images and portfolios; drop to 60 for thumbnails and icons. Then adjust per image — different images have different tolerances.

Format beats quality

Re-encoding a JPEG at quality 75 to WebP at quality 75 typically saves another 25-34% for free. Browsers have supported WebP for years; there's no reason not to use it for photographic content. PNG is different: it's lossless, so no quality slider can make it dramatically smaller — convert screenshots and logos to WebP instead.

Find your actual breakpoint

Don't guess. Compress the same image at several quality levels and compare side by side. The moment you notice degradation, step back up 5%. That number is your image's personal sweet spot — it varies by subject (a gradient sky falls apart before a busy texture does).

The workflow I use

Most compression tools upload your image to a server, which is slow and a privacy question mark for client assets. I use a browser-based compressor that does everything locally — no upload, no signup, no size caps. The one I keep bookmarked is the CodeToolbox Image Compressor; its side-by-side preview and live quality slider make finding the breakpoint a 30-second task.

Remember: file size is a design constraint like any other. Know your quality curve, respect the 70% rule, and always compare before you download.

HSL vs HEX: Why I Moved My Design Tokens to HSL

zhihu wu — Tue, 04 Aug 2026 13:43:05 +0000

I used to define every color in my CSS as a hex code. #3b82f6 here, #1e40af there. It worked fine — until the day I needed a hover state, a disabled state, and a dark-mode variant of the same blue. Suddenly I was doing mental math on hex pairs and hoping the result looked right.

The problem with hex is that it's written for machines, not humans. You can't look at #2563eb and guess what it looks like 15% darker. HSL fixes that by describing color the way we actually perceive it: a hue on a wheel (0-360 degrees), a saturation percentage, and a lightness percentage.

Take the blue #2563eb. In HSL it's hsl(221, 83%, 53%). Want a darker shade for a hover state? Drop the lightness: hsl(221, 83%, 43%). Want a lighter tint for a page background? Raise it: hsl(221, 83%, 93%). No calculators, no hex arithmetic — you move one number and the color does exactly what you expect.

This becomes even more powerful with CSS custom properties. Instead of scattering hex values across your stylesheet, store the channels once:

:root {
  --brand-h: 221;
  --brand-s: 83%;
  --brand-l: 53%;
}
.btn-primary {
  background: hsl(var(--brand-h) var(--brand-s) var(--brand-l));
}
.btn-primary:hover {
  background: hsl(var(--brand-h) var(--brand-s) calc(var(--brand-l) - 10%));
}

Now your entire theme derives from three numbers. Dark mode becomes a single media query that swaps lightness values. Tailwind's shade scale (50 through 950) is essentially lightness variations of one hue — which is why it feels so cohesive out of the box.

If you're still thinking in hex, try this experiment: pick your brand color, convert it to HSL, and spend a day using the lightness slider instead of hunting for "a slightly darker blue" on color-picker websites. It's a small mental shift, but it makes your color system dramatically easier to maintain — and it's one less tool you need when someone asks for "the same blue but a bit lighter."

💡 When I need to explore shades or convert between formats, I use the CodeToolbox Color Picker — it shows HEX, RGB, and HSL side by side with live sliders, so I can watch how changing lightness ripples through all three formats in real time. Everything runs locally in the browser, so the color I'm working on never leaves my machine.

3 Markdown Mistakes I Fixed After Previewing My Drafts

zhihu wu — Sat, 01 Aug 2026 13:05:51 +0000

3 Markdown Mistakes I Fixed After Previewing My Drafts

I write in Markdown every day — READMEs, Dev.to posts, GitHub issues, documentation. I thought I knew the syntax cold. Then I started previewing my drafts before publishing and realized I was making the same three mistakes over and over.

Here's what I caught, and how you can avoid them.

1. Tables That Look Fine in Raw Markdown — But Break on Render

This is the most common one. You write a table like this:

| Name | Type | Default |
|------|------|---------|
| timeout | number | 30 |
| retries | number | 3 |

Looks perfect. But then you add a fourth column to one row without updating the header separator line — and suddenly GitHub renders a broken mess. The separator line needs exactly the same number of pipes as every other row. Miss one, and the table falls apart.

Fix: Always preview your tables. A real-time preview catches misalignment instantly — you'll see the render fail while you're still editing, not after you've pushed to main.

2. Code Blocks That Eat Your Backticks

You want to show a literal backtick inside a code block. Standard Markdown uses triple backticks for code fences, but what if your code contains triple backticks? The renderer gets confused about where the code block ends.

The original Markdown spec says: Use \`backticks\` for inline code.

json
{
"example": "this is inside a fenced code block"
}

markdown

In the raw editor, this looks fine. But the renderer sees the first

, then the inner

json starts a nested fence (or ends the outer one early). The result is half your content vanishing from the rendered output.

Fix: Use four backticks for the outer fence when your code contains triple backticks. Or better — preview it. You'll see the break immediately.

3. Numbered Lists That Reset (When You Don't Want Them To)

You write:

1. Install dependencies
2. Configure the environment

Some paragraph in between.

3. Run the app
4. Open localhost:3000

Markdown sees that paragraph as a list break. Items 3 and 4 start a new list — so they render as "1. Run the app, 2. Open localhost:3000" instead of continuing the numbering. This is correct per the spec, but it's rarely what you intended.

Fix: Indent the paragraph with four spaces to keep it inside the list item, or indent the continuation numbers. Or just preview it — the reset will jump out at you.

The Lesson: Preview Before You Publish

All three of these mistakes look correct in raw text. That's the trap — Markdown is designed to be readable in source form, so errors are invisible until you render them.

I now paste every README update, every Dev.to draft, and every documentation change into a Markdown preview tool before pushing. It's a free, client-side tool — nothing leaves your browser — and it catches these formatting bugs in seconds. The split-pane view (edit on the left, preview on the right) makes it obvious when a table misaligns, a code fence breaks, or a list resets unexpectedly.

If you write Markdown regularly, make previewing a habit. Five seconds of checking beats a pull request comment pointing out your broken table.

5 Developer Writing Tasks That Need More Than Just a Word Count

zhihu wu — Fri, 31 Jul 2026 13:08:55 +0000

5 Developer Writing Tasks That Need More Than Just a Word Count

We obsess over clean code, but how often do we sweat over the words around our code? Commit messages, API docs, README files — these are the interfaces between your code and other humans. A word counter gives you more than just a number; it gives you constraints that sharpen your writing.

1. The 50/72 Rule for Commit Messages

Git convention says: 50 characters for the subject line, 72 for body lines. Why 50? Because git log --oneline truncates at 50. Why 72? Because git log indents by 4 and terminals are 80 columns wide. Paste your commit message into a counter and check: is your subject under 50 characters? Are your body lines under 72? This one habit makes your git history readable on any terminal.

2. Meta Descriptions Under 160 Characters

Google displays roughly 150–160 characters of your meta description. Every character past 155 is wasted. For developers building landing pages, docs sites, or portfolios, this is the difference between a click and a scroll-past. Write your description, paste it in, trim to 155 characters.

3. READMEs People Actually Read

The average developer spends 15 seconds scanning a README before deciding whether to dive in. If your word count is over 500 words and your paragraph count is over 8, you're writing a novel. Use the sentence count — if the average exceeds 25 words per sentence, your README feels dense. Break it up.

4. Error Messages That Help

"An error occurred." — 3 words, zero value. "Failed to connect to database 'users' at localhost:5432 — connection refused." — 12 words, actionable. Good error messages have a sweet spot: 10–25 words, one sentence. Paste them into a counter and ask: is this long enough to be useful but short enough to be scanned?

5. API Documentation Chunks

Nobody reads API docs cover-to-cover. They scan for the endpoint they need. Keep parameter descriptions under 30 words — anything longer means you're burying the signal. Paste your draft endpoint docs into a counter and check each parameter description.

Quick check: If you're writing any of the above and want instant feedback, CodeToolbox Word Counter runs in your browser — no uploads, no signup. Just paste, check, and ship.

URL Encoding Demystified: encodeURIComponent vs encodeURI

zhihu wu — Wed, 29 Jul 2026 13:08:46 +0000

You are debugging a broken API call. The URL looks fine in your browser, but the server returns 400. You stare at the query string: ?q=hello world&filter=active. There is your problem — that space.

URL encoding is one of those things every developer encounters but few fully understand. Let us fix that.

The Two JavaScript Functions (and Why Both Exist)

encodeURI() is for entire URLs. It preserves characters that have structural meaning: :, /, ?, &, #. Use it when you have a complete URL and just need to make it safe.

encodeURIComponent() is for individual parameter values. It encodes everything except A-Z a-z 0-9 - _ . ! ~ * ' ( ). The & in your filter value? Encoded. The = in your base64 token? Encoded.

encodeURI("https://example.com/search?q=hello world")
// → "https://example.com/search?q=hello%20world"

encodeURIComponent("hello world")
// → "hello%20world"

The rule: encodeURI() for the whole URL, encodeURIComponent() for each parameter value. Mix them up and you either break the URL structure or leave dangerous characters unencoded.

The Double-Encoding Trap

If you encode a string that is already encoded, the % signs get re-encoded to %25. hello%20world becomes hello%2520world. The server decodes once and gets hello%20world — still encoded. A second decode gives you the original, but most servers only decode once.

Spot double-encoding by looking for %25 in your output. If you see it, decode first, then re-encode.

%20 vs + for Spaces

In query strings, HTML forms use + for spaces (application/x-www-form-urlencoded). In path segments, use %20 (RFC 3986). encodeURIComponent() always outputs %20, which is safe everywhere. If your server expects +, use %20 anyway — most modern frameworks handle both.

The Quick Fix

Next time a URL misbehaves, paste it into a decoder, inspect what is actually being sent, and fix the encoding at the source. A free tool like CodeToolbox URL Encoder does this in your browser — no server uploads, instant results.

Base64 Decoded: What Actually Happens When You Hit 'Encode'

zhihu wu — Sun, 26 Jul 2026 13:06:07 +0000

Base64 is not encryption — it's encoding. If you paste Hello into a Base64 encoder and get SGVsbG8=, no secret key was used. The algorithm just translates binary data into 64 printable ASCII characters so it can travel through text-only channels like email, JSON, and URLs.

The Algorithm in Plain English

Take your input bytes and group them in sets of 3 (24 bits total).
Split those 24 bits into four 6-bit chunks.
Each 6-bit value (0-63) maps to one character in the Base64 alphabet: A-Z, a-z, 0-9, +, /.
If the input isn't a multiple of 3 bytes, add = padding to round it out.

For Hello (5 bytes), the encoder processes bytes 0-2 as one group (producing 4 characters), then bytes 3-4 as a 2-byte group (producing 3 characters + 1 =). Result: 8 characters — SGVsbG8=.

Where You Encounter Base64 Every Day

Data URIs — embed images directly in HTML/CSS as data:image/png;base64,iVBOR..., saving HTTP requests for small icons.
JWT tokens — the payload section of every JSON Web Token is Base64-encoded JSON.
Email attachments — MIME uses Base64 to send binary files through text-only SMTP.
API authentication — Basic Auth encodes username:password as a Base64 string in the Authorization header.
Inline SVGs — embed vector graphics in a single HTML file without external dependencies.

Common Gotchas

Standard vs URL-safe. Standard Base64 uses + and /, which break in URLs. URL-safe Base64 replaces them with - and _ and strips the = padding. If you are encoding something for a query string, always use the URL-safe variant.

Base64 expands data by ~33%. Encoding 1 MB of binary produces ~1.33 MB of text. For large payloads, gzip the original data before Base64-encoding to offset the bloat.

It is not encryption. Anyone can decode Base64 with zero effort. Never use it as a security measure — it provides exactly zero confidentiality.

Try it yourself: Base64 Encoder/Decoder — free, no signup, works entirely in your browser with no server uploads.

Cron Jobs in 2026: Docker, CI/CD, and Why Your Old crontab Tricks Still Work

zhihu wu — Fri, 24 Jul 2026 13:06:59 +0000

Cron has been scheduling Unix jobs since the 1970s, and it is not going anywhere. But the way we run cron jobs has shifted: from bare-metal servers to Docker containers, from crontab files to CI/CD YAML, and from cron.d to Kubernetes CronJobs. Here is what changed — and what has not.

1. Cron Inside Docker

Docker containers prefer a single foreground process, so running a cron daemon inside a container feels unnatural. Three modern approaches:

Host cron + docker exec: Run cron on the host, and have each entry invoke docker exec container command. Zero container changes, works today.
supercronic: A drop-in crontab-compatible runner that logs to stdout/stderr. Perfect for containers whose log drivers expect stdout.
ofelia: A Docker-native scheduler that reads job config from container labels instead of a crontab file.

2. CI/CD Cron: GitHub Actions & Friends

GitHub Actions, GitLab CI, and Jenkins all support cron-triggered pipelines. The syntax is identical to standard 5-field cron:

# GitHub Actions — runs every weekday at 9 AM UTC
on:
  schedule:
    - cron: "0 9 * * 1-5"

Key difference: CI/CD schedulers use UTC by default, not your local timezone. A 0 0 * * * job that reads "midnight" actually fires at midnight UTC — which may be 8 PM your time. Always verify the timezone offset.

3. The Classic Traps Have Not Changed

Some mistakes transcend the platform:

Weekday numbering: 0 is Sunday (POSIX), but Quartz Scheduler and some libraries start at 1 for Sunday. Check your platform convention.
OR logic: When both day-of-month AND day-of-week are set, the job fires when EITHER matches — not both. This catches everyone at least once.
Minimal environment: Cron runs without your shell PATH, aliases, or environment variables. Use absolute paths and set SHELL=/bin/bash.

Quick tip: I use a free visual cron generator to build expressions, see human-readable descriptions, and preview the next 5 execution times before pasting into production. Beats memorizing field order at 2 AM.

What is the worst cron bug you have deployed? Mine was a timezone mismatch that sent customer emails at 3 AM local time instead of 9 AM.