Words, precision
and power.
The details behind text processing, encoding, and document formats.
✦ AI-powered — understands natural language
Why `"abc" is "abc"` Is True But `"hello world" is "hello world"` Might Not Be — String Interning, Ropes, and Concatenation Complexity
Why Your Database Uses snake_case, Your JSON Uses camelCase, and Your .env Uses SCREAMING_SNAKE_CASE — and What Breaks When You Mix Them
Database column names, JSON fields, environment variables, and CSS classes each use different casing conventions — and each choice reflects a constraint from where that identifier is used. Here's why PostgreSQL lowercases your column names, the JSON snake_case vs camelCase cross-ecosystem problem, why environment variables are SCREAMING_SNAKE_CASE, and the file-name case-sensitivity bug that works on macOS and breaks on Linux production servers.
How Counting Characters Can Identify a Language — and Why It Gets More Reliable With Every Word
A character-counting algorithm can identify a language from a short text sample because every language has a dramatically different character frequency signature — English peaks at E (12.7%), German at E (17.4%) with distinct umlauts, Spanish with high A and the ñ character. Here's how n-gram comparison against language profiles works, why accuracy improves with text length, where language detection fails (code-switching, similar languages, proper nouns), and applications beyond language detection.
Why Copy-Paste From PDFs and Word Docs Silently Breaks Your Database: The Invisible Character Problem
A non-breaking space (U+00A0) looks identical to a regular space but doesn't trim with standard .trim(), doesn't match in string comparisons, and passes "not empty" validation on fields that look blank to users. Here's the taxonomy of invisible Unicode characters that cause real data quality bugs (not security exploits — the accidental kind from PDF and Word paste), where they come from, the specific bugs they cause, and how to reliably detect and clean them.
Where Lorem Ipsum Actually Comes From: Cicero, a Mid-Word Cut, and Centuries of Corruption
"Lorem ipsum" isn't a real Latin phrase — it's literally the tail end of "dolorem ipsum" ("pain itself"), cut off mid-word from a genuine passage of Cicero's philosophy, then scrambled and partially invented over centuries of typesetting. Here's the actual source text, how a coherent philosophical passage became nonsense, and why the "fakeness" arguably works in its favor as placeholder text.
Title Case Isn't One Rule: How AP, Chicago, and MLA Disagree on Prepositions and Hyphens
"The Art of War" or "The Art Of War"? AP style capitalizes 4+ letter prepositions; Chicago and MLA lowercase all prepositions regardless of length. Here's how major style guides disagree on prepositions, why hyphenated compounds are the hardest case for any automated title-case tool, and why "to" as an infinitive marker needs different treatment than "to" as a preposition.
Why Truncating Text at "Exactly 100 Characters" Is Harder Than It Looks: UTF-8, Word Boundaries, and HTML
Truncating at exactly 100 characters sounds simple — until you're splitting a multibyte UTF-8 sequence and producing invalid text, cutting mid-word and leaving "fo" dangling, or cutting HTML and leaving unclosed tags. Here's the byte vs code point vs grapheme cluster distinction, the word-boundary backtracking algorithm, why HTML truncation requires an actual parser (not string slicing), and why your ellipsis length has to come out of the character budget before you cut.
Why Text Diff Tools Work at Line Level (Not Character Level): Edit Distance, Granularity, and the Unified Diff Format
The simplest possible text diff — "what characters changed?" — is the Edit Distance problem, with an O(n×m) solution too slow for document-scale text. This is why practical diff tools work at line level, with a second character-level pass only within changed lines. Here's how granularity (character, word, line, sentence, structural) changes both what's shown and what's computationally feasible, the unified diff format explained, and why structured diffs for JSON/HTML need tree-level comparison rather than line-level.
Huffman Coding: How "E Is the Most Common Letter" Becomes Smaller ZIP Files and PNG Images
Every ZIP file, PNG image, and gzip-compressed page relies on the same observation as the previous article's frequency analysis: characters aren't equally frequent, so assigning shorter codes to common symbols and longer codes to rare ones saves space. Here's how Huffman coding builds optimal variable-length codes from frequency data, why "prefix-free" codes need no separators, how this fits into larger compression pipelines like DEFLATE, and why already-compressed data resists further compression.
Frequency Analysis: How Counting Letters Breaks Caesar Ciphers, Substitution Ciphers, and Why Modern Encryption Is Immune
A Caesar cipher can be broken in seconds — not by trying all 25 shifts, but by counting which ciphertext letter appears most often and matching it against English's most common letter, "E." Here's how frequency analysis breaks substitution ciphers, why polyalphabetic ciphers like Vigenère were designed to defeat it, and why modern encryption (AES, RSA) is immune to this entire category of attack.
Find & Replace Beyond Basics: Regex Capture Groups, Multi-Cursor Editing, and Safe Project-Wide Replace
Find-and-replace with regex capture groups doesn't just substitute text — it can restructure it, swapping argument order or reformatting dates by reusing captured values in the replacement. Here's how capture-group replacements work, when multi-cursor editing is the better tool instead, case-modification syntax for naming-convention conversions, and safe practices for project-wide replace operations.
Reversing Text Has Three Completely Different Meanings — Here's How Each Works and When You'd Use It
Reversing text has three completely different interpretations: reverse every character, reverse word order, or reverse line order — and each produces different output from identical input. Here's where each is actually used (character reversal for palindromes, line reversal for the Unix tac command and log files), the palindrome variants that require different reversal types, and why reversing Arabic/Hebrew code points is different from displaying them right-to-left.
Why ROT13's Encode Button and Decode Button Do the Same Thing — and Why That's the Point
ROT13 shifts each letter by 13, and shifting by 13 again returns you to the start — because 13 is exactly half of 26, and the English alphabet has 26 letters. This self-inverse property means "encode" and "decode" are literally the same operation, which is exactly why ROT13 became the standard for Usenet spoilers and forum answers: one button, symmetric, no separate decode tool needed. Here's the math, the variants (ROT5, ROT18, ROT47), and where self-inverse operations appear elsewhere.
