Generating What You Need: QR Codes, Passwords, IDs & Files

Software has two quite different sources of random numbers, and they are not interchangeable. A general-purpose generator produces a sequence that looks statistically random but is computed from a seed — anyone who learns the seed can reproduce every value it will ever emit. A cryptographically secure generator draws from operating-system entropy and is designed so that observing past output tells you nothing about future output.

For shuffling a playlist or picking a random colour, the fast one is fine. For anything that must be unguessable — a password, a token, a reset link, a session identifier — only the secure one will do. Browsers expose it as the Web Crypto API, and it is the reason a password generated in a modern browser is genuinely unpredictable rather than merely scrambled.

Password advice spent two decades emphasising symbols, digits and mixed case, and largely got the priority backwards. What resists guessing is entropy — the number of possibilities an attacker must work through — and length raises that far faster than character variety does.

The comparison worth noticing is row two against row three: sixteen lowercase letters comfortably beat eight characters of every type. This is why the modern guidance from NIST dropped mandatory composition rules and mandatory rotation, both of which pushed people toward short passwords with predictable substitutions and a trailing number.

The entropy figures above only hold for passwords generated at random. A password you invented is worth far less than its length suggests, because human choices cluster — capital at the front, digits at the end, a substituted @ for a, a word from a small pool. Attack tools model all of it. Passphrases work only when the words are chosen randomly by a machine, not selected by you.

A UUID is a 128-bit identifier designed so that independent systems can mint IDs without coordinating and still never collide. The version tells you how the bits are chosen, and the choice has real consequences for database performance.

Collisions with v4 are not a practical concern — with 122 random bits you would need to generate billions per second for decades before the probability became meaningful. The real problem with v4 as a primary key is ordering. Random keys scatter inserts across a B-tree index, fragmenting it and destroying locality; v7 puts a timestamp in the high bits so new rows land together, which is why it has become the default recommendation for new schemas.

Avoid v1 in anything new. It embeds the generating machine's MAC address, which is information leakage for no benefit now that v7 exists.

A QR code is a two-dimensional encoding of a text string, and everything clever about it comes from two properties: it stores a surprising amount of data, and it keeps working when damaged.

Error correction is the reason a QR code still scans with a logo over the middle or a coffee ring across one corner. Four levels exist, recovering roughly 7%, 15%, 25% and 30% of the code respectively. Higher correction means more redundancy, which means a denser code for the same content — so the practical choice is the lowest level that survives the conditions it will live in. A code on a screen needs almost none; one on a sticker in a car park needs the highest.

The other lever is content length. A QR code encoding a 200-character URL is visibly denser than one encoding a short link, and denser codes need better cameras, better printing and more physical size. Shortening the URL is usually the cheapest way to make a code scan reliably.

• →A URL is the common case, and including https:// makes it open directly rather than being treated as plain text.
• →WiFi credentials let a guest join a network by pointing a camera at a card, with no password typed or dictated.
• →A vCard carries full contact details — useful on business cards, though the size pushes the code toward density.
• →Plain text, phone numbers, and pre-filled SMS or email messages all work, and none of them require an internet connection to decode.

One-dimensional barcodes remain everywhere in retail and logistics, and the main decision is which symbology fits the job. Code 128 is the general-purpose choice, encoding the full ASCII set compactly, which makes it right for asset tags, internal part numbers and shipping references. EAN-13 and UPC-A are the retail standards and are not free-form — they encode a specific registered product number.

Most symbologies include a check digit computed from the other digits, so a misread is detected rather than silently accepted as a different valid code. This is why you cannot simply invent an EAN-13: a number with the wrong final digit will be rejected by any scanner that validates it, which is most of them.

For printing, quiet zones matter more than people expect. A barcode needs clear space either side — roughly ten times the width of the narrowest bar — or scanners cannot find the edges. A code squeezed tight against a label border is the single most common reason an otherwise correct barcode will not read.

Placeholder content exists to let you judge a design or exercise a system before the real content exists, and the two jobs want quite different material.

For layout, Lorem Ipsum works precisely because it is meaningless. Nonsense Latin stops reviewers reading the words and reacting to the copy when you wanted feedback on the typography, and its word-length distribution approximates English closely enough that the block looks right.

For testing software, meaningless data is actively harmful. Realistic mock data — plausible names, addresses, emails, dates, currency values — exposes the bugs that placeholder strings hide: the name with an apostrophe that breaks a query, the address that runs to three lines, the date that crosses a month boundary, the value that reveals a rounding error. A test suite fed nothing but foo and 123 will pass right up until a real user arrives.

PDF is the format documents end up in when they need to look identical everywhere, and the everyday operations are mundane: merge several files into one, pull out a range of pages, reorder, or turn a set of photographed pages into a single document to send.

The reason this is worth doing locally is what those documents usually are. The files people most often need to merge or split are the ones they would least like to hand to a stranger — signed contracts, bank statements, identity documents, medical letters, scanned forms. A tool that assembles them without a round trip removes the question of what happened to the copy.

Countdown timers, stopwatches and Pomodoro intervals look like the simplest thing a page can do, and they are the category where naive implementations most reliably drift.

The reason is that the browser's scheduling functions are a request rather than a guarantee. Asking to be called every 1,000 milliseconds gets you something a few milliseconds late each time, because the callback waits for whatever else the page is doing. Counting those callbacks to measure elapsed time accumulates every one of those delays — over a 25-minute session the error is easily tens of seconds.

Background tabs make this sharper. Browsers throttle inactive tabs heavily to save battery, so a timer counting ticks in a background tab runs slow or effectively stops — which is precisely what happens whenever someone starts a focus timer and switches away to work, the one behaviour a Pomodoro timer is designed for. Reading the clock is immune, because the elapsed time is correct the moment the tab wakes.

This is also why the Pomodoro technique itself works better with a timer that is honest about the interval. The method's value comes from a fixed, uninterrupted block followed by a real break; a timer that quietly stretches its own interval removes the constraint that made the technique useful.