DEV Community: zhihu wu

5 Cron Gotchas That Silently Break Your Jobs (and How to Fix Them)

zhihu wu — Sun, 06 Sep 2026 13:04:02 +0000

Cron looks simple: five fields and a command. But some of its oldest quirks are exactly where jobs fail silently — usually at 3 AM when nobody is watching. Here are five gotchas I've hit (or watched teammates hit), with the fixes.

1. Day-of-month and day-of-week are OR, not AND

30 2 1 * 1 does NOT mean "the first of the month AND Monday." Cron fires the job if EITHER field matches — so this runs at 2:30 AM on the 1st of every month AND at 2:30 AM every Monday. To target a true "first Monday," keep the schedule simple and add a guard inside the command that checks the day of month is within the first 7 days.

2. Cron runs in the server's timezone, not yours

0 0 * * * means midnight in whatever timezone the host is set to. Docker containers default to UTC, and cloud VMs are often UTC too — so your "daily midnight" job can silently run at 8 AM your time. Check with the date command in the same environment, and use CRON_TZ if your cron implementation supports it.

3. The percent sign means newline

In a crontab entry, % is translated to a newline. A command like date +%Y-%m-%d will break or behave oddly. Escape it as \% — or better, put the logic in a script file and keep the crontab line trivial.

4. Cron gives you a minimal environment

Cron does not source your shell profile. PATH is often just /usr/bin:/bin, so anything installed via nvm, pyenv, or a project virtualenv "works in my terminal" but fails only under cron. Fix: use absolute paths in the script and export PATH at the top of the script itself.

5. Overlaps and silence

If a job runs longer than its interval, cron happily starts a second instance — wrapped in flock to prevent it. And if stdout isn't redirected and no mail daemon exists, error output quietly disappears. Redirect to a log file and add an external health check so a dead job actually alerts you.

Gotchas like these are why I test a schedule before deploying it. When I need to decode an unfamiliar expression or build one from scratch, I use the free CodeToolbox Cron Generator — it validates each field and explains the schedule in plain language, and everything runs locally in your browser, so nothing gets uploaded.

UUIDv7 vs UUIDv4: Why Time-Sortable IDs Are Winning (and When v4 Is Still Right)

zhihu wu — Fri, 04 Sep 2026 13:03:21 +0000

If you have ever used a random UUID as a database primary key and watched writes slow down as the table grew, it was not your imagination — and the fix became an official standard back in May 2024.

The problem with random keys

A UUID v4 is 122 bits of pure randomness. Insert a few million rows and every new row lands at a random position in your B-tree index. The database keeps splitting pages and evicting cache lines, and your writes pay for it. On write-heavy tables this fragmentation is a real, measurable cost.

What UUIDv7 changes

UUIDv7 keeps the familiar 128-bit shape but replaces the first 48 bits with a Unix timestamp in milliseconds. The remaining bits are still random. Because IDs generated close together are close in value, new rows append near the end of the index instead of poking holes in the middle. B-tree locality improves, page splits drop, and you get a free bonus: rows are roughly sortable by creation time, which makes "latest first" queries and cursor pagination noticeably cheaper.

Adoption is already here

Python 3.14 added uuid.uuid7() to the standard library
The uuid npm package ships uuidv7() (v11+)
Go's google/uuid has NewV7()
Postgres has the pg_uuidv7 extension, and built-in support keeps spreading

The trade-offs you should know

UUIDv7 leaks timing information — the timestamp is right there in the ID. That is fine for database keys but wrong for security tokens, session IDs, or anything where you do not want to reveal when a record was created. Use v4 or a dedicated random token there.

Also, "time-sortable" is best-effort, not a guarantee: if one process generates IDs in a tight loop, or a machine clock rolls back, ordering can drift. For most backends that is noise; for strict event ordering you need a sequence, not a UUID.

When v4 is still the right call

If your table is read-heavy or sits under roughly ten million rows, v4 is perfectly fine — the index overhead is negligible compared with the simplicity. v4 is also what crypto.randomUUID() in browsers and Node.js produces today, and it works everywhere with zero new tooling. Do not migrate an existing happy system just to chase v7.

Try it yourself

When I need a UUID in the middle of debugging, I use a free client-side generator at CodeToolbox — everything runs in the browser, nothing is uploaded, and the page includes a quick v4 vs v7 vs ULID comparison if you want the full picture before choosing an ID strategy for your next project.

Why Your JSON Won't Parse: 6 Invisible Character Traps (and How to Fix Them)

zhihu wu — Tue, 01 Sep 2026 13:02:29 +0000

You've written JSON that looks perfectly fine. Braces match, keys are quoted, commas are in place. Yet JSON.parse() throws Unexpected token at a position that makes no sense.

Sound familiar? Here are six invisible traps that break perfectly "correct-looking" JSON — and how to spot each one.

1. Trailing commas

{"a": 1, "b": 2,} — the comma after the last item is invalid in strict JSON (it's legal in JavaScript objects, which is why it sneaks in). Editors rarely flag it. Drop the final comma and it parses.

2. Smart (curly) quotes

Copy JSON out of a word processor, email client, or chat app and the quotes come back curly: " and " instead of ". JSON only accepts the straight double quote (U+0022). Curly quotes are the #1 cause of "my JSON works in my head but not in code".

3. The hidden BOM

Files saved as UTF-8 with BOM start with an invisible byte sequence before the first {. JSON.parse() sees it as an unexpected token — the classic "error at line 1, column 1" mystery. Save as UTF-8 without BOM and it disappears.

4. Non-breaking spaces

A space that isn't a space. NBSP (U+00A0) copied from formatted text looks like whitespace to your eyes but is invalid JSON syntax when it hides between keys and colons.

5. Single quotes and unquoted keys

{'a': 1} and {a: 1} are valid JavaScript — but not JSON. RFC 8259 requires double-quoted keys and values. Hand-written config files drift into JS-object syntax all the time.

6. Duplicate keys don't throw — they silently overwrite

{"id": 1, "id": 2} parses fine, but the first value is silently discarded. Different parsers disagree on which value wins, so this causes subtle, hard-to-debug data loss.

How to debug these fast

Don't eyeball it — get a precise error location. Paste the payload into a formatter that reports the exact line and column of the first syntax error (a BOM shows up as an error at position 0, a dead giveaway). A collapsible tree view also makes duplicate keys easy to spot after a successful parse.

I use the free JSON Formatter on CodeToolbox for this — it's 100% client-side (your data never leaves the browser), reports exact error positions, and switches between format / minify / validate modes. No signup, no uploads.

The 30-second fix checklist

Replace curly quotes with straight quotes
Drop trailing commas
Save without BOM
Double-quote every key

Nine times out of ten it's one of these. Happy parsing!

How to Compress Images for the Web Without Losing Quality

zhihu wu — Mon, 31 Aug 2026 13:08:19 +0000

Images are the single biggest contributor to slow page loads — yet most developers only compress them once, at export time, and never think about it again. A 5MB photo that should weigh 150KB is the difference between a page that loads in 0.8s and one that crawls past 4s on mobile.

Here are the compression techniques that actually matter, in order of impact:

1. Resize before you compress.
If your original is 4000x3000px but your layout only needs 1200px wide, every pixel beyond that is wasted bytes. Resizing first, then compressing, routinely turns a 5MB photo into under 100KB.

2. Use WebP as your output format.
WebP is typically 25-35% smaller than JPEG at the same visual quality, and every modern browser supports it. For screenshots and UI mockups, converting PNG to WebP is often an 80-90% reduction.

3. Find the quality breakpoint, don't guess.
Start at 100% quality and slide down while previewing the result side by side. The moment you notice degradation, bump back up 5%. For most web images that lands between 70-80% — visually near-identical, 60-80% smaller.

4. Match quality to usage.
Hero images and photography portfolios deserve ~85%. Thumbnails and icons can drop to 60% where detail matters less. One setting for everything means you're either bloating thumbnails or degrading heroes.

5. Watch your Core Web Vitals.
Image weight is the #1 factor in Largest Contentful Paint (LCP). Cutting image size on your top pages can shave seconds off LCP on mobile — and since Google uses LCP as a ranking signal, it's a free SEO win alongside the speed gain.

When I need to batch-process images quickly, I use a browser-based compressor at codetoolbox.pro/tools/image-compressor — it runs entirely locally via the Canvas API, so nothing gets uploaded to a server, which matters when you're compressing screenshots of internal dashboards or customer data.

The rule of thumb: if a page's images are under 100KB total, you're probably fine. If a single image is over 500KB, it's costing you ranking and conversion. Compress once, deploy everywhere.

Hashing vs Encryption vs Encoding: The Difference Every Developer Gets Wrong

zhihu wu — Sat, 29 Aug 2026 13:08:58 +0000

Hashing, encryption, and encoding sound similar — but they solve completely different problems. Mixing them up causes security bugs, broken APIs, and confused code reviews. Here's the mental model that finally made it click for me.

Encoding: not security at all

Encoding converts data from one format to another so it can be transported or displayed. Base64, URL encoding, hex — all reversible without any key. btoa()/atob(), encodeURIComponent, Buffer.from(x, 'base64') — none of these protect anything. Anyone can decode them. Encoding is about compatibility, not confidentiality.

Hashing: one-way by design

A hash function maps any input to a fixed-length output. SHA-256 always produces 64 hex characters, whether the input is "hi" or a 2GB video. Three properties matter:

Deterministic — same input, same hash, always.
One-way — you can't reverse a hash into its input.
Avalanche effect — changing one character flips roughly half the bits.

That's why hashes verify integrity: file checksums, Git commit IDs, npm lockfiles, API signatures. You can't "decrypt" a hash — you compare hashes.

Encryption: reversible, but only with a key

Encryption is the only one that provides confidentiality. AES, RSA, ChaCha20 — ciphertext turns back into plaintext, but only with the right key. TLS, HTTPS, disk encryption, JWT payloads — all encryption.

The one-line cheat sheet

Concept	Reversible?	Needs a key?	Purpose
Encoding	Yes	No	Format conversion (Base64, URL encoding)
Hashing	No	No	Integrity checks (SHA-256 checksums)
Encryption	Yes	Yes	Confidentiality (AES, RSA)

Common bugs this clears up

Storing passwords with MD5/SHA-256? That's hashing — fine for integrity, but passwords need slow salted algorithms like bcrypt or argon2.
"Let me encrypt this string with Base64" — Base64 is encoding; it obfuscates nothing.
Verifying a downloaded file? Compare its SHA-256 checksum — a hash, not encryption.

💡 When I need to quickly hash a string or verify a checksum, I use the SHA-256 Hash Generator on CodeToolbox — it computes SHA-1/256/384/512 right in the browser, nothing is uploaded.

What's a hashing/encryption mixup you've seen in production? Drop it in the comments.

URL Encoding 101: Why %20 Isn't a Space (and When to Use encodeURIComponent)

zhihu wu — Wed, 26 Aug 2026 13:08:21 +0000

Ever pasted a URL with spaces, Chinese characters, or an emoji into an API call and watched it explode with a 400 error? That's URL encoding — or the lack of it — biting you.

What URL encoding actually is

URLs are restricted to a small set of characters per RFC 3986: A-Z, a-z, 0-9, and a handful of reserved symbols (-, _, ., ~). Everything else — spaces, non-ASCII characters, and the reserved delimiters themselves (/, ?, &, #, %, =) — must be percent-encoded.

Each encoded character becomes a % followed by two hex digits:

Character	Encoded
space	`%20`
`/`	`%2F`
`?`	`%3F`
`&`	`%26`
`#`	`%23`
`你`	`%E4%BD%A0`

The classic JavaScript bug

encodeURI() encodes everything EXCEPT the reserved characters — which is why it's fine for the URL as a whole but WRONG for query values:

const q = "C# & JavaScript";
fetch(`/search?q=${encodeURI(q)}`);        // broken: # and & survive
fetch(`/search?q=${encodeURIComponent(q)}`); // "C%23%20%26%20JavaScript"

When a value contains #, &, or =, those characters change the meaning of the URL if they pass through raw. encodeURIComponent() escapes all of them — use it for every query parameter and path segment you build dynamically.

Decoding matters just as much

You'll hit the reverse problem too: a file literally named my%20file.pdf because someone double-encoded it, or log output showing %E4%BD%A0 where a Chinese word should be. A reliable decoder that handles UTF-8 and edge cases saves real debugging time.

If you ever need to quickly encode or decode a string — or double-check what your code is actually sending — I keep coming back to CodeToolbox URL Encoder. It encodes and decodes in both directions with full UTF-8 support, no uploads, no signup required.

How Many Pages Is 1000 Words? The 500/250 Rule Every Writer Should Know

zhihu wu — Mon, 24 Aug 2026 13:09:36 +0000

Word counts and page counts live in different worlds. Your editor says 1,000 words, your client asks for "three pages," and the PDF comes out at four. Who's right? Everyone, sort of — page count depends entirely on formatting. Here's the rule of thumb that actually works.

The 500/250 rule

A standard page in a 12pt font with 1-inch margins holds roughly:

500 words per page single-spaced
250 words per page double-spaced

That's it. It's not precise — font choice, line spacing, margins, and images all shift the number — but it's accurate enough to plan with. If you're writing a 2,000-word article, expect it to land around 4 single-spaced pages or 8 double-spaced. If it comes out noticeably different, the layout (not the writing) is what changed.

Why editors and Word disagree

Microsoft Word's page count reflects its layout engine: your margins, your font metrics, your paragraph spacing. Google Docs renders slightly differently, so the same text can "be" 5 pages in one and 5.3 in the other. Neither is wrong — page count is a rendering detail, not a property of the text itself.

Word count, by contrast, is a property of the text. Ten words is ten words in any editor. That's why word count is the contract between writers, clients, and publishers: it's the only number that doesn't change when you switch fonts.

When to use which

Quoting a deliverable → use word count. "A 1,500-word blog post" is unambiguous.
Estimating print layout → use the 500/250 rule. It gets you in the ballpark before you open a layout tool.
Meeting a platform limit → use character count. Twitter/X caps at 280 characters, meta descriptions at ~155, App Store descriptions at 4,000.

The practical workflow

Write the draft.
Check the word count.
If you're targeting pages, divide by 500 (single-spaced) or 250 (double-spaced).
If you're targeting a character limit, trim against the character count, not the word count.

When I need these numbers fast, I paste the draft into a free online word counter that shows words, characters, sentences, and estimated reading time in real time — no upload, everything stays in the browser. It makes the word-count-vs-pages dance a five-second check instead of a formatting fight.

Next time someone asks for "three pages," you'll know the real question is "about 1,500 words" — and you can deliver with confidence.

How Much House Can You Actually Afford? The 28/36 Rule, Explained

zhihu wu — Fri, 21 Aug 2026 13:26:41 +0000

Buying a home? Before you look at listings, run the numbers on what you can actually afford — not what the bank pre-approves you for.

The 28/36 rule in 30 seconds

Lenders use two debt-to-income ratios:

Front-end DTI: your housing payment (principal + interest + taxes + insurance) should be at most 28% of your gross monthly income.
Back-end DTI: ALL your debt payments (housing + car + student loans + credit cards) should be at most 36%.

Example: $7,000/month gross income -> housing payment target = $1,960 (28%). If you also pay $400/month in car and student loans, your max housing payment drops to $2,120 (36% back-end) — and the 28% cap wins at $1,960.

Why the rule matters

The 28% cap isn't about approval — it's about margin. Life happens: job changes, medical bills, surprise repairs. A payment that eats 40% of your income leaves almost no room to absorb those. Banks will lend you more than you should borrow; the rule keeps the decision in your hands.

Run your own numbers

Don't trust the calculator on the listing site — they assume a 20% down payment and often skip taxes and insurance. Punch in your real numbers instead:

Gross monthly income x 0.28 = your housing payment ceiling
Adjust loan amount, rate, and term until the payment lands at or under that ceiling

I use the free Loan Calculator for this — it shows the full amortization schedule and total interest, so you also see how much the house really costs over 30 years. No signup, and everything runs locally in your browser.

The takeaway

The 28/36 rule gives you a defensible, math-backed answer to "how much house can I afford" — before a realtor or lender tells you theirs. Run the numbers first, then go shopping.

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.