DEV Community: Sarfaraz

Your SSL Certificate Is Expiring and Nobody Told You (Until Now)

Sarfaraz — Tue, 01 Sep 2026 02:38:46 +0000

There's a special kind of production incident where nothing changed in your code, no deploy went out, and yet everything is on fire. Nine times out of ten, that's an SSL certificate that quietly expired at 3 AM on a Sunday.

It's one of the most avoidable outages in web development, and also one of the most common — because certificates don't fail loudly in advance. They just work, right up until the exact second they don't.

Why this keeps happening

Certificates aren't a "set once" thing. Most are valid for 90 days (shorter than they used to be, thanks to Let's Encrypt and browser vendors pushing shorter lifespans) or up to a year for some paid CAs. That means renewal is a recurring chore, not a one-time setup step — and recurring chores are exactly the kind of thing that fall through the cracks when:

The person who set up the cert three renewal cycles ago has left the team
Auto-renewal (certbot, ACME, load balancer integration) is assumed to be working but silently isn't
A subdomain or staging environment was added later and never got its own monitoring
The cert is fine, but the chain is incomplete — valid on your server, broken on some clients

That last one is sneaky. A certificate can look perfectly fine in your own browser (which caches intermediate certs) while failing for a fraction of your users whose devices don't have the intermediate cert cached — usually because the server isn't sending the full chain.

What "checking your SSL" actually means

It's not just "is it expired." A proper check covers:

Expiry date — obviously, but also how soon. 30 days out is a warning; 3 days out is an incident.
Chain completeness — is the full chain (leaf → intermediate → root) being served, or just the leaf cert?
Hostname match — does the certificate actually cover the domain (and subdomains, if it's a wildcard) being served?
Protocol and cipher support — is the server still allowing deprecated protocols like TLS 1.0/1.1 that some compliance frameworks and browsers now flag or block?
Issuer trust — is it signed by a CA that's actually in modern trust stores, and not self-signed in a production context?

Missing any one of these can mean "works for me" while a meaningful slice of real users get a scary browser warning or an outright connection failure.

The cost of getting this wrong

Browsers don't politely degrade on an expired or mismatched cert — they show a full-page warning that most non-technical users won't click past.
API clients and mobile apps often fail harder than browsers — no warning screen, just a TLS handshake error and a support ticket.
SEO and trust signals take a hit; search engines and security scanners both penalize broken HTTPS.
Compliance audits (PCI-DSS, SOC 2, etc.) will flag weak protocols or incomplete chains even if the site "works."

The frustrating part is that all of this is checkable in advance — it just requires actually looking, on a schedule, instead of finding out when a customer emails you.

A faster way to look

Rather than pulling out openssl s_client every time (which, fine, works, but nobody wants to remember the flags), I built a quick certificate checker that surfaces expiry date, days remaining, chain status, and issuer info for any domain in one pass:

👉 SSL Certificate Checker

It's part of samtoolkit.com — small, client-side developer tools (JWT decoder, HTTP status/header reference, webhook bin, env validator, and others). Nothing you check gets logged or stored server-side.

If you've had a cert-expiry outage story, I'd genuinely like to hear it in the comments — everyone has one, and they're always more avoidable in hindsight than they felt at 3 AM.

The HTTP Status Code You're Returning Is Probably Wrong (And Nobody Notices)

Sarfaraz — Tue, 01 Sep 2026 02:33:03 +0000

Quick test: what's the difference between 401 and 403? What about 502 vs 503? If you had to pause even for a second, you're not alone — and you're also not off the hook, because the client code (or the poor human) on the other end of your API is making decisions based on that number.

Status codes and headers are one of those "I'll just wing it" corners of web development. Everyone's shipped a 500 for a validation error at least once. This post is a quick, practical pass through the ones that actually matter, the ones people mix up, and the headers most APIs quietly get wrong.

Why this is worth five minutes

A status code is a contract. It tells the caller what kind of thing just happened without them reading your response body:

Should I retry this request?
Is this my fault or the server's?
Should I refresh my auth token?
Is this safe to cache?

Get the code wrong, and you break that contract. Clients retry things they shouldn't, cache things they can't, or silently swallow errors because your 200 said everything was fine.

The mix-ups that happen constantly

401 vs 403 — 401 Unauthorized actually means "I don't know who you are" (no or invalid credentials). 403 Forbidden means "I know exactly who you are, and the answer is no." Mixing these up gives users the wrong recovery path — one says "log in again," the other says "stop asking."

404 vs 410 — 404 says "not found," which invites retries and crawlers to keep checking. 410 Gone says "this existed and is never coming back." If you deleted a resource on purpose, 410 is the more honest answer and it tells search engines to stop indexing it.

500 vs 502 vs 503 — 500 is your app's own bug. 502 Bad Gateway means you're a proxy/gateway and the upstream service sent garbage. 503 Service Unavailable means you're intentionally down (maintenance, overload) and should usually come with a Retry-After header. These three get used interchangeably in a lot of codebases, and it makes on-call debugging harder than it needs to be.

PUT vs PATCH response codes — a successful PUT that creates a new resource should return 201 Created; one that updates an existing one should return 200 OK (or 204 No Content if you're not returning a body). A lot of APIs just return 200 for everything, which quietly discards useful information.

The headers people forget exist

Cache-Control — the single header most responsible for either a snappy site or a stale one. no-store, no-cache, and max-age=0 all mean subtly different things.
ETag combined with If-None-Match — lets clients skip re-downloading unchanged resources. Massively underused outside of CDNs.
Retry-After — pairs with 429 and 503 to tell clients exactly when to come back, instead of making them guess with exponential backoff.
Content-Security-Policy — not just a security checkbox; misconfiguring it is one of the more common reasons a perfectly good frontend "randomly" stops loading fonts or scripts.
Vary — if your response changes based on a header like Accept-Encoding or Authorization, and you're not setting Vary, your CDN or browser cache can serve the wrong version to the wrong user.

Where this actually bites you

A retry storm because your API returned 500 instead of 429 for rate limiting, so clients treated a "slow down" as a random failure and hammered you harder.
A broken cache because a response with private data went out with Cache-Control: public.
A frontend team that built retry logic around 503 because your team returned it for something that was actually a permanent 410.

None of these are exotic edge cases — they're the ordinary Tuesday bugs that come from treating status codes and headers as decoration instead of protocol.

A reference beats a memory test

Honestly, memorizing all ~60 status codes and every header's exact semantics isn't a good use of anyone's time. I put together a quick lookup tool that covers status codes (grouped by category, with the "what it actually means" and "when to use it" spelled out) and common request/response headers, so you can check instead of guess mid-code-review:

👉 HTTP Status Code & Header Reference

It's part of samtoolkit.com — a set of small, client-side developer tools (JWT decoder, .gitignore generator, env validator, webhook bin, and a few others). Nothing gets uploaded anywhere; everything runs in your browser.

If you've got a favorite status-code horror story — a 200 that lied to you, a 418 used unironically in production, whatever — drop it in the comments. I collect these.

Stop Hand-Editing Text Case — You're Wasting Time You Don't Need To

Sarfaraz — Sat, 29 Aug 2026 13:06:04 +0000

The Ten Seconds You Pay Over and Over

You've done this: you paste a column of Product Name headers into your code and need product_name for a database schema. Or a designer hands you Hero Title copy and your CSS needs hero-title classes. Or you're renaming a variable from userEmail to match a user_email API response.

None of these take long individually — select the word, retype it, fix the capitalization, move to the next one. But you do this constantly, across renaming variables, cleaning up spreadsheet headers, converting API field names, prepping CSS classes, and reformatting copy. Ten seconds here, twenty there. It adds up to real, avoidable time spent on something with zero decision-making involved.

Why It's Always Manual

Casing conversion is one of those tasks that's too small to justify writing a script for in the moment, but tedious enough to be annoying every single time you hit it by hand:

It's rarely just one word. A list of 40 column headers going from Title Case to snake_case is 40 manual edits, or a regex you have to half-remember how to write.
The rules aren't always obvious. Converting getUserID to snake_case — is it get_user_id or get_userid? Acronyms and abbreviations make "just retype it" trickier than it sounds.
Every language has a different convention. JavaScript wants camelCase, Python and SQL want snake_case, CSS and URLs want kebab-case, constants want SCREAMING_SNAKE_CASE. Moving data between a frontend, a backend, and a database often means converting the same field name three different ways in one sitting.

None of this is hard. It's just friction — the kind that's easy to tolerate because each instance is small, right up until you count how often it happens in a week.

Just Paste It and Convert

The fix is exactly as unglamorous as the problem: a tool that takes text and spits out every casing format at once, so you copy whichever one you need instead of retyping anything.

Case Converter on SamToolkit does this — paste in text (a single term or a whole list) and get camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE, Title Case, and more, instantly, entirely in your browser. No upload, no account, no waiting on a page to load a heavier app just to flip some text into a different format.

It's a genuinely small tool. That's the point — it's meant to be faster to open, paste, and copy than it is to do the conversion by hand, even for a single word.

Where This Actually Saves Time

A few places this comes up more than people expect:

Renaming variables to match a style guide after a linter flags a batch of inconsistent names.
Converting spreadsheet or CSV headers into valid database column names or API field names in one pass.
Prepping CSS class names or IDs from design copy or content docs that come in Title Case or Sentence case.
Matching naming conventions across a stack — same concept, different casing, in your frontend, backend, and database schema.

None of these are hard problems. They're just the kind of small, repeated friction that's worth removing once and not thinking about again.

What's your most-used text conversion — camelCase, snake_case, something else? Curious what comes up most in other people's workflows.

5 JWT Mistakes That Quietly Break Your Auth Security

Sarfaraz — Sat, 29 Aug 2026 12:58:28 +0000

A Token That "Just Works" Isn't the Same as a Secure One

JWTs are everywhere — API auth, SSO, session management — because they're simple to generate and easy to pass around. That simplicity is also exactly why they get misused. A JWT can be perfectly well-formed, verify correctly, and still be a security hole, because the format doesn't protect you from bad decisions about what goes inside it or how it's checked.

Here are the mistakes that show up most often — and how to catch them by actually looking at what's inside your tokens.

1. Trusting the `alg` Header Too Much

A JWT's header names the signing algorithm — HS256, RS256, none. The catch: that field is set by whoever created the token, and some JWT libraries will happily verify a token using whatever algorithm the header claims, including none (no signature at all) if the server-side code doesn't explicitly reject it.

This is the classic "alg confusion" attack: an attacker takes a token meant to be verified with an RSA public key, changes the header to HS256, and signs it using that same public key as an HMAC secret — because public keys are, by definition, public. If your verification code doesn't pin down the expected algorithm, it can be tricked into accepting a forged token.

Fix: always specify and enforce the exact algorithm you expect server-side; never let the token's own header decide how it gets verified.

2. Sensitive Data Sitting in Plaintext

The "signed" part of JSON Web Token only guarantees the payload hasn't been tampered with — it says nothing about who can read it. The header and payload are just Base64URL-encoded, not encrypted. Anyone with the token — a browser extension, a proxy log, a teammate glancing at devtools — can decode it in seconds and read every claim inside.

Tokens with emails, internal role names, permission lists, or anything resembling PII in the payload are handing that data to anyone who intercepts the token, signature or not.

Fix: keep the payload to what's needed for authorization (subject ID, expiry, minimal scopes). If you need to transmit sensitive data, that's what encrypted JWTs (JWE) or a server-side session lookup are for.

3. No Expiry, or an Expiry Nobody Checks

A JWT without an exp claim is valid forever, which means a leaked token — from a log file, a compromised device, an old bookmarked URL — stays usable indefinitely. And even when exp is present, it's only useful if the verification code actually checks it; a surprising number of custom JWT-handling implementations decode the payload and manually pull out claims without running full verification, silently skipping the expiry check entirely.

Fix: always set a short, sensible exp, and confirm your verification path is actually validating it — not just parsing the payload and trusting it.

4. Reusing the Same Secret Everywhere

It's common for a codebase to have one JWT_SECRET env var used for every kind of token — access tokens, refresh tokens, password reset links, email verification tokens — all signed with the same key. If any one of those flows has a vulnerability (say, a reset-token endpoint that leaks a valid signature), an attacker can potentially forge tokens for a completely different flow, since they all trust the same secret.

Fix: use distinct signing secrets (or key pairs) per token purpose, so a compromise in one flow doesn't cascade into every other one.

5. Not Actually Looking at What's Inside Your Tokens

This sounds almost too simple, but it's the root cause behind most of the above: teams generate JWTs, ship them, and never actually inspect what ends up in the payload in production. Claims drift over time as features get added — someone adds a isAdmin boolean "temporarily" for testing and it's still there eight months later, sitting in every token, readable by anyone who decodes one.

The fastest way to catch this is to just decode a real token and read it, the same way you'd review an API response. JWT Decoder on SamToolkit does exactly that — paste a token in and instantly see the decoded header and payload, with nothing sent to a server (it runs entirely in your browser, so you're not pasting production tokens into someone else's backend). It's a fast way to sanity-check exactly what a token exposes, verify the algorithm and expiry are what you expect, and catch stray claims before they become a habit.

The Underlying Principle

JWTs give you integrity (tamper detection) for free. They give you confidentiality and correct verification only if you set them up carefully. Treat every claim you add to a payload as something a stranger might read, treat the alg header as attacker-controlled input, and periodically decode your own tokens to check what's actually shipping — before someone else does it for you.

What's the worst JWT misconfiguration you've caught in a code review? Share it below.

The .env Mistake That Takes Down Production (And How to Catch It Before You Deploy)

Sarfaraz — Sat, 29 Aug 2026 12:47:03 +0000

The 2 AM Deploy That Wasn't Supposed to Break Anything

You merge the PR. CI is green. You deploy. Five minutes later, your error tracker lights up like a Christmas tree.

TypeError: Cannot read properties of undefined (reading 'apiKey')

You SSH in, check the logs, and there it is — STRIPE_API_KEY was never set in the production environment. It was in .env.example. It was in your local .env. Someone just forgot to add it to the deploy target.

Nothing in your build pipeline caught it, because there was nothing to catch. The app didn't know that variable was required until it tried to use it — in production, in front of real users.

Why This Keeps Happening

Environment variables are one of the least-tested parts of most codebases, mostly because they don't feel like "real" code:

They're invisible until runtime. A missing or malformed env var doesn't show up in a type checker or a linter. It shows up when that specific code path executes — which might be five minutes after deploy, or five weeks, if it's a rarely-hit feature flag or a seasonal job.
.env.example drifts. Someone adds a new required variable, updates their own .env, and forgets to update the example file or tell the team. Weeks later, a new hire or a fresh CI runner fails in a confusing way.
"String" isn't a type check. Even when a variable is present, nothing verifies it's actually a valid URL, a number in range, or one of an expected set of values. PORT=abc will pass any "is it set" check and then fail somewhere deep in your HTTP server setup.
Different environments, different expectations. A variable might be optional in development but required in production, or vice versa (test API keys vs. live ones). Most setups don't encode that distinction anywhere.

Individually, each of these is a minor oversight. Together, across a team and a growing list of environment variables, they turn into a steady trickle of preventable outages and "works on my machine" debugging sessions.

Validate the Shape, Not Just the Presence

The fix isn't "be more careful" — it's making the shape of your environment explicit and checking it automatically, the same way you'd validate an API request body.

A solid env validation setup answers three questions before your app is allowed to boot:

Is everything required actually present?
Does each value match the type and format it should? (number, boolean, URL, enum, non-empty string, etc.)
Are the rules different per environment, and are those differences intentional?

If you're using something like zod, envalid, or @t3-oss/env-nextjs in a Node/TypeScript project, you can express this as a schema and fail fast at startup with a clear error message instead of a cryptic runtime crash three layers deep. The principle holds regardless of stack — Python's pydantic-settings, Go's envconfig, and similar libraries all do the same job: define the contract once, validate it every time the app starts.

Checking It Before It Even Gets to CI

Schema validation at startup is the safety net for your running app, but a lot of these mistakes happen before code is even deployed — while writing a .env file by hand, or copying one from a teammate and missing a line.

That's the gap a quick pre-flight check fills: paste in your .env content and instantly see what's missing, misformatted, or inconsistent with what the app expects — before you've built, deployed, or asked a teammate to debug it with you.

That's exactly what Env Validator on SamToolkit does. It's a free, browser-based tool — nothing you paste is uploaded or logged, it all runs client-side — that checks your environment variables for the common failure modes above: missing required keys, empty values, malformed URLs and numbers, and inconsistencies between what you have and what your app expects.

It's the kind of five-second check that's easy to skip under deadline pressure and expensive to skip when it causes an incident.

Make It a Habit, Not a Hero Moment

The teams that stop having "it worked locally" env incidents usually do two small things:

Add schema validation at app startup, so a bad environment fails loudly at boot instead of quietly at runtime.
Get in the habit of double-checking .env files — especially before a new environment setup or a deploy — with a quick tool pass rather than a manual read-through.

Neither takes long. Both are far cheaper than a 2 AM page.

Have an env-related horror story of your own? Drop it in the comments — misery loves company.

I Found an API Key in My Git History. Here's How I Stopped Doing That.

Sarfaraz — Fri, 28 Aug 2026 16:27:27 +0000

A while back I ran git log -p on an old side project and found a .env file sitting in the history, plaintext API key and all. The file wasn't even in the current commit — I'd deleted it two commits later. Didn't matter. It was in the history forever, in a public repo, for anyone to git clone and scroll back through.

That's the moment .gitignore stopped being "some file GitHub adds when you create a repo" and started being something I actually think about on day one of every project.

Why this keeps happening

.gitignore is one of those files everyone knows they should set up properly, and almost nobody does, for a pretty simple reason: nobody wants to sit down and type out ignore patterns for node_modules, .env, __pycache__, .vscode, bin/, obj/, .DS_Store, and whatever else your specific stack throws off. So the usual paths are:

Skip it, git add ., and hope for the best
Copy a .gitignore from a random old project that only half-matches your current stack
Add patterns reactively, after git status shows you something ugly

All three have the same failure mode: anything ignored late was already trackable before you added the rule, which means it can already be committed. Once a secret is in your Git history, adding it to .gitignore afterward does nothing — the file is still there in every clone, every fork, every previous commit. You have to rewrite history to actually remove it, which is its own headache.

The other failure mode is just noise. Without a proper .gitignore, your diffs fill up with bin/Debug/, node_modules/, build artifacts, and IDE config — real changes get buried, and every PR review takes longer because reviewers are scrolling past junk.

The fix: get it right before your first commit

I built a .gitignore Generator into SamToolkit specifically so "set up .gitignore properly" stops being a step people skip.

You search and multi-select whatever's in your stack — frameworks (Docker, React, Next.js), editors (VS Code, JetBrains), languages (Node, Python, Java, Rust, Go, Blazor/.NET), and OS (macOS, Windows) — and it merges everything into one file. A few details that matter more than they sound:

It de-dupes across stacks. Pick Node and Python together and you won't get the same log/cache patterns listed twice — the tool merges the selected templates into one clean file instead of concatenating them.

Each stack gets its own labeled section, so when you add a language six months from now you can find and extend the right block instead of guessing where a pattern lives.

It's additive. Starting a repo as pure Node and adding Python later? Re-run it, select both, and get the combined file — no manually diffing two template files to merge them by hand.

Live preview before you commit to anything (pun intended) — you see the generated file, then copy or download it.

Like the rest of SamToolkit, it runs entirely client-side — nothing about your stack selections gets sent anywhere.

The actual habit to build

The tool solves the "typing it out is annoying" problem, but the underlying habit matters more than the tool: .gitignore is a day-one file, not a day-30 file. Generate it before your first git add, not after git status embarrasses you.

And if you've already committed something sensitive — a .gitignore entry won't save you retroactively. You'll need git rm --cached at minimum, and a history rewrite (git filter-repo or BFG) if it's already pushed somewhere public.

👉 samtoolkit.com/tools/gitignore-generator

Curious — has anyone else had a "found a secret in old Git history" moment? What was it?

Why Your README Still Sucks (And How I Fixed Mine in 90 Seconds)

Sarfaraz — Fri, 28 Aug 2026 16:20:54 +0000

You just finished a project. The code works, the tests pass, and you're proud of it. Then you get to the README, and your energy dies on the spot.

So you type # Project Name, maybe a one-line description, and call it done. Six months later someone opens your repo, sees nothing but a title and a wall of source files, and closes the tab.

I've done this more times than I'd like to admit. And I don't think it's laziness — I think READMEs are just a genuinely awkward writing task.

Why READMEs are harder than they look

A good README has to do several unrelated jobs at once:

Sell the project in the first three lines, before anyone scrolls
Prove it's alive with badges (build status, version, license, coverage)
Get someone from zero to running code with install and usage steps
Signal what stack it's built on, so people self-select in or out
Set expectations for contributors, if you're open to them

That's marketing copy, technical writing, and project management, all crammed into one Markdown file — usually written at 11pm right before you push. No wonder most READMEs are either a single sentence or a copy-pasted template with half the placeholders still in it.

The annoying part is that the shape of a good README barely changes between projects. Title, badges, description, tech stack, install, usage, license — it's the same skeleton every time. Yet we free-hand it from scratch on every single repo.

The fix: stop writing the skeleton by hand

That repetition is exactly what pushed me to build a README Generator into SamToolkit — a free, client-side tool that turns a short form into a polished README.md.

The idea isn't to write your README for you — it's to stop you from re-typing the same boilerplate every time so you can spend your energy on the two paragraphs that actually matter: what the project does and why someone should care.

A few things about how it's built:

Three templates, not one. You pick between Minimal, Detailed/Enterprise, and Open Source + Contributing, depending on whether you're shipping a weekend script or a project that expects pull requests.

Badges without hunting for shields.io syntax. Build status, version, coverage, license, and a "PRs welcome" badge are all toggles — no remembering markdown-badge syntax.

A real tech stack picker. Instead of typing out language and framework names, you select from a proper list — TypeScript, Rust, Go, ASP.NET Core, Docker, Kubernetes, Postgres, and dozens more — and it renders cleanly into the README.

The sections people forget. Installation steps, a usage example block, an API reference stub, contributing guidelines, and a screenshot/GIF placeholder are all one-click additions instead of things you remember only after someone opens an issue asking "how do I even run this?"

License text without copy-pasting from GitHub's license picker. MIT, Apache 2.0, GPLv3, BSD 3-Clause, Unlicense, or Proprietary — pick one and the correct boilerplate is in.

Live preview, then copy or download. You see the rendered Markdown as you build it, and you either copy it straight into your repo or download the file.

And since it's built the same way as the rest of SamToolkit, the whole thing runs client-side in your browser — nothing you type gets sent to a server.

Try it

If your last three repos all have a README that's one line and a "TODO," this will take less time than writing this sentence took me:

👉 samtoolkit.com/tools/readme-generator

It's free, no signup, and it's one of ~30 browser-based dev tools on the site — worth a look if you're the kind of developer who'd rather generate boilerplate than write it by hand.

What do you always forget to put in your README? Curious what people consider the "must-have" section I might be missing.

I Built a Free Timestamp Converter That Never Sends Your Data Anywhere

Sarfaraz — Thu, 27 Aug 2026 08:36:13 +0000

If you've ever worked with logs, APIs, or databases, you know the drill: you're staring at a number like 1735689600 and you need to know what date that actually is — right now, not after signing up for something.

I got tired of the usual options: sketchy ad-heavy sites, tools that quietly send your data to a server, or switching to a Python shell just to run datetime.fromtimestamp(). So I added a Timestamp Converter to samtoolkit.com — one of ~30 browser-based developer utilities on the site, all running entirely client-side.

What it does

Converts Unix timestamps (seconds or milliseconds) to human-readable dates and back
Supports UTC and local timezone views side by side
Handles common formats developers actually deal with — ISO 8601, RFC 2822, epoch
Live "current timestamp" ticker so you can grab "now" instantly
No sign-up, no API calls, no data leaving your browser

Why client-side matters here

Timestamps often show up next to sensitive context — user IDs, order numbers, log lines you shouldn't be pasting into a random third-party server. Since samtoolkit.com tools are built with Blazor WebAssembly, the conversion logic runs entirely in your browser. Nothing you type is ever sent anywhere. You could unplug your ethernet cable mid-conversion and it would keep working.

This is the same philosophy behind the rest of the toolkit — JSON formatters, base64 encoders, regex testers, and now this — all "nothing leaves your browser" by design.

Try it

👉 Timestamp Converter on samtoolkit.com

It's free, has no ads blocking the actual tool, and works offline once loaded. If you run into an edge case it doesn't handle well, I'd genuinely like to hear about it in the comments — most tools on the site started as exactly that kind of feedback.

samtoolkit.com is a growing collection of privacy-first developer tools — no tracking, no accounts, everything runs in your browser.

Cron Syntax Is a Trap — Here's a Builder That Explains What You're Actually Scheduling

Sarfaraz — Wed, 26 Aug 2026 03:36:58 +0000

Nobody writes cron expressions from memory. Not really. You either copy one from Stack Overflow and hope, or you open crontab.guru, squint at it for a minute, and copy-paste the result into a deploy config you'll never look at again — until it fires at 3 AM on a Saturday instead of 3 PM on a weekday, and now you're debugging a scheduler instead of sleeping.

The problem isn't that cron syntax is hard, exactly. It's that it's terse — five fields, no labels, and a handful of special characters (*, /, -, ,) that all mean something different depending on which field they're in. 0 3 * * 1-5 is either "every weekday at 3 AM" or a typo away from something else entirely, and there's nothing in the string itself that tells you which one you actually wrote.

That's the gap the Cron Expression Builder on SamToolkit is built to close.

Build it visually, read it in plain English

Instead of starting from five blank fields and hoping you remember the order (minute, hour, day-of-month, month, day-of-week — in that order, always forget it), the builder gives you a form: pick a frequency, pick the times, pick the days. It generates the expression for you.

But the more useful part runs the other direction. Paste in an existing cron expression from a codebase you've inherited, and it explains it back to you in plain English — "runs at 3:00 AM, Monday through Friday" — so you're not reverse-engineering someone else's scheduling logic field by field.

A few things that come up constantly and are easy to get wrong by hand:

Day-of-month vs. day-of-week interactions — cron treats these as OR'd together when both are restricted, which trips up almost everyone the first time
Step values (*/15 for every 15 minutes) vs. ranges (9-17) vs. lists (1,15 for the 1st and 15th)
Common schedule shortcuts like @daily, @hourly, and @reboot, and what they expand to under the hood
Timezone ambiguity — cron expressions don't carry timezone info themselves, and the builder flags that explicitly so you don't assume UTC when your server is running IST

A quick example

Say you want a job that runs every 15 minutes, but only during business hours, Monday to Friday. The instinct is often something like:

*/15 9-17 * * 1-5

That looks right — and mostly is — but it's worth checking what "9-17" actually means here: it runs the job at :00, :15, :30, :45 past every hour from 9 through 17, which includes the 17:45 run. If you meant "stop by 5 PM sharp," you actually want a narrower end hour, or an accepted trailing run trimmed depending on your intent. The builder's plain-English readout — "at every 15th minute past every hour from 9 through 17, Monday through Friday" — makes that boundary explicit instead of leaving you to work it out from the raw digits.

Here's what scheduling that in Node might look like with node-cron:

const cron = require('node-cron');

// Every 15 minutes, 9 AM–5:45 PM, Mon–Fri
cron.schedule('*/15 9-17 * * 1-5', () => {
  console.log('Running business-hours job:', new Date().toISOString());
}, {
  timezone: 'Asia/Kolkata'
});

Note the explicit timezone option — this is exactly the kind of thing that's invisible in the cron string itself and easy to forget until a deploy to a server in a different region quietly shifts every job by 5.5 hours.

Why it's worth using over guessing

Cron bugs are uniquely annoying because they don't fail loudly — a misconfigured schedule doesn't throw an error, it just runs at the wrong time, or not at all, and you usually find out from a missed report or a stale cache rather than a stack trace. Verifying the expression against a plain-English explanation before it goes into a crontab or a CI config catches that class of bug before it becomes a production mystery.

Like the rest of the toolkit, it runs entirely client-side — no data leaves your browser, and nothing about your infrastructure or schedule gets logged anywhere.

Try it

If you've got a cron expression sitting in a deploy script that you're not 100% sure you understand anymore, paste it in and see if the explanation matches what you expect.

👉 Cron Expression Builder on SamToolkit

It's one of 30 free, browser-only developer tools on SamToolkit — no sign-up, nothing tracked, nothing uploaded.

What's the worst cron scheduling mistake you've made? Drop it in the comments.

Stop Guessing: A Free Regex Tester That Actually Explains Your Pattern

Sarfaraz — Wed, 26 Aug 2026 03:33:14 +0000

Every developer has a regex horror story. Mine involves a "simple" email validator that quietly rejected half our signups for three days before anyone noticed. The pattern looked right. It just wasn't.

Regex is one of those skills where reading a pattern back is way harder than writing it. ^(?=.*[A-Z])(?=.*\d).{8,}$ makes sense while you're typing it out character by character — and then completely unreadable the moment you close the tab and come back a week later.

That's the exact gap I wanted to close with the Regex Tester & Explainer on SamToolkit.

What makes it different from "just another regex tester"

There's no shortage of regex testers online. Most do one thing well: highlight matches in real time as you type. That's useful, but it only answers "does this match?" — not "why does this match, and what happens with the next weird edge case someone throws at it?"

The tool adds a plain-English breakdown alongside the match highlighting. Instead of staring at (?:\d{3}[-.\s]?){2}\d{4} and mentally parsing it token by token, you get each piece explained in order — group boundaries, quantifiers, character classes, lookaheads — so you can actually verify your pattern does what you meant, not just what it happens to match on your one test string.

A few things it handles that come up constantly in real work:

Named and unnamed capture groups, broken out individually so you can see exactly what each one grabs
Flags (g, i, m, s, u) with a note on how each one changes the matching behavior
Live match highlighting against your own sample text, updated as you type — no submit button, no page reload
Common gotchas flagged inline — unescaped special characters, greedy quantifiers that will overmatch, missing anchors

A quick example

Say you're validating Indian mobile numbers and land on something like:

^[6-9]\d{9}$

Looks fine. Ten digits, starting with 6 through 9. But paste it in and test against +91 98765 43210 and it fails immediately — because the anchors don't account for a country code or formatting characters. The explainer walks through why: the ^ and $ anchors require the entire string to be exactly ten digits with nothing else, so any prefix or spacing breaks the match. That's the kind of thing that's obvious once someone points it out and completely invisible when you're staring at your own pattern for the fifth time.

Once you've confirmed the pattern in the tester, dropping it into actual JS is the easy part:

const mobileRegex = /^(?:\+91[\s-]?)?[6-9]\d{9}$/;

function isValidIndianMobile(input) {
  const cleaned = input.replace(/\s+/g, ' ').trim();
  return mobileRegex.test(cleaned);
}

isValidIndianMobile('9876543210');       // true
isValidIndianMobile('+91 98765 43210');  // true
isValidIndianMobile('123456789');        // false — wrong starting digit

Notice the fixed version wraps the optional country code in a non-capturing group (?:\+91[\s-]?)? — exactly the kind of change that's obvious in the tester's breakdown but easy to miss when you're just eyeballing the raw pattern.

Why it runs the way it does

Like the rest of the toolkit, this one is 100% client-side. Your pattern and your test string never leave the browser — nothing is sent to a server, nothing is logged. That matters more than it sounds: regex testing often happens on real data — actual customer emails, actual log lines, actual PII you're trying to write a validator around. A tool that ships that data off to a backend for "processing" is a tool you shouldn't be pasting real data into. This one, you can.

It also means it's fast. No network round-trip between keystrokes, no debounce lag waiting for a server response — the match highlighting and explanation update instantly because the regex engine is running right there in your tab.

Try it

If you've ever shipped a regex that worked in your one test case and broke in production, this is built for exactly that failure mode. Give it a real pattern — something gnarly from your own codebase — and see if the explanation matches what you thought it did.

👉 Regex Tester & Explainer on SamToolkit

It's one of 30 free, browser-only developer tools on SamToolkit — no sign-up, nothing tracked, nothing uploaded.

What's the worst regex bug you've shipped? Drop it in the comments — I'll try to break the tester with it.

I Built a Free Color Palette Extractor That Never Uploads Your Images

Sarfaraz — Tue, 25 Aug 2026 08:33:38 +0000

Ever needed to pull a color scheme out of a photo, a screenshot, or a client's logo — and hesitated for a second because you didn't want to upload it to some random website?

That hesitation is exactly why I built the Color Palette Extractor on SamToolkit, a free, privacy-first developer tools site. Every tool on SamToolkit runs entirely in your browser using Blazor WebAssembly — nothing you upload ever touches a server.

What it does

Drop in any image — a photo, a mockup, a brand logo — and the tool analyzes the pixel data locally and returns a ready-to-use palette:

Dominant colors, ranked by prevalence
Hex, RGB, and HSL values for every extracted color, one click to copy
A quick preview swatch strip so you can eyeball the palette before using it
Works with PNG, JPG, and WebP

It's built for the moment you're staring at a reference image thinking "I just need these five colors as hex codes" — no account, no upload limit, no image leaving your machine.

Why client-side matters here

Color extraction is a genuinely good fit for running entirely in-browser:

Privacy — brand assets, unreleased designs, or client photos never leave your device.
Speed — no round trip to a server means the palette appears almost instantly after you drop the file.
No limits — since there's no backend processing cost, there's no arbitrary cap on how many images you can run through it.

Under the hood, the tool decodes the image into a pixel buffer, buckets similar colors together (so you get a clean palette instead of 40 near-identical shades of blue), and sorts by frequency — all inside WebAssembly, at native-ish speed.

A quick example

Say you're building a landing page and the client sent over a product photo with a color scheme you want to match. Instead of eyeballing hex codes in a screenshot tool:

Open the Color Palette Extractor
Drag the image in
Copy the hex codes straight into your CSS:

:root {
  --color-primary: #2f6f4f;
  --color-secondary: #e8b04b;
  --color-accent: #c1443c;
  --color-neutral: #f4f1ea;
}

Done — no design software required.

Part of a bigger toolkit

The Color Palette Extractor is one of about 30 browser-based utilities on SamToolkit — JSON formatters, image converters, text diff tools, and more, all following the same rule: nothing leaves your browser.

If you try it out, I'd love to hear what you think — and if there's a color or design tool you wish existed, drop it in the comments.

🔗 Try the Color Palette Extractor

3 Free CSS Generators That'll Save You From Fighting box-shadow, gradient, and border-radius Syntax

Sarfaraz — Tue, 25 Aug 2026 02:30:39 +0000

If you've ever spent 20 minutes nudging box-shadow offsets, or hand-writing a linear-gradient() only to get the angle wrong three times in a row, you already know: CSS values that look simple are often the most fiddly to write from memory.

That's exactly the itch these three tools scratch. They're all free, run entirely in your browser (nothing gets uploaded anywhere), and give you a live preview so you can just drag sliders until it looks right — then copy the generated CSS straight into your stylesheet.

1. Box Shadow Generator

Getting a shadow to look "just right" — not too harsh, not invisible — usually means tweaking four or five values at once: horizontal offset, vertical offset, blur radius, spread radius, and color/opacity. Doing that by editing raw CSS and refreshing the browser every time is slow.

The Box Shadow Generator gives you sliders for each of these with an instant live preview, plus support for multiple stacked shadows (handy for that popular "layered depth" look). When it looks right, hit copy and you've got production-ready CSS.

Good for: card hover effects, modal elevation, neumorphic UI, button depth.

2. Gradient Generator

Gradients are deceptively easy to get wrong — the wrong angle or color stop placement can make a background look muddy instead of smooth. This tool lets you pick your colors, drag stop positions, and switch between linear and radial gradients while watching the preview update live.

Good for: hero backgrounds, button fills, subtle section dividers, dark-mode-friendly overlays.

3. Border Radius Generator

border-radius looks like a one-value property until you need asymmetric corners (top-left different from bottom-right) for that "organic blob" or "squircle" look that's become common in modern UI design. Writing that shorthand by hand — border-radius: 30% 70% 70% 30% / 30% 30% 70% 70% — from memory is basically impossible.

This generator lets you drag each corner independently and see the shape update in real time, so you can land on something that actually looks intentional instead of guessing at percentages.

Good for: blob shapes, avatar frames, illustrative UI accents, card corner treatments.

Why browser-based tools like these are worth bookmarking

None of these three require an account, a download, or sending your design data anywhere — everything runs client-side. That matters if you care about privacy, but it also just means they're fast: no loading spinners, no server round-trips, just instant feedback as you adjust values.

You can find all three (and more browser-based dev utilities) at samtoolkit.com.

Which of these do you reach for most — shadows, gradients, or border-radius? Let me know in the comments.

DEV Community: Sarfaraz

Your SSL Certificate Is Expiring and Nobody Told You (Until Now)

Why this keeps happening

What "checking your SSL" actually means

The cost of getting this wrong

A faster way to look

The HTTP Status Code You're Returning Is Probably Wrong (And Nobody Notices)

Why this is worth five minutes

The mix-ups that happen constantly

The headers people forget exist

Where this actually bites you

A reference beats a memory test

Stop Hand-Editing Text Case — You're Wasting Time You Don't Need To

The Ten Seconds You Pay Over and Over

Why It's Always Manual

Just Paste It and Convert

Where This Actually Saves Time

5 JWT Mistakes That Quietly Break Your Auth Security

A Token That "Just Works" Isn't the Same as a Secure One

1. Trusting the alg Header Too Much

2. Sensitive Data Sitting in Plaintext

3. No Expiry, or an Expiry Nobody Checks

4. Reusing the Same Secret Everywhere

5. Not Actually Looking at What's Inside Your Tokens

The Underlying Principle

The .env Mistake That Takes Down Production (And How to Catch It Before You Deploy)

The 2 AM Deploy That Wasn't Supposed to Break Anything

Why This Keeps Happening

Validate the Shape, Not Just the Presence

Checking It Before It Even Gets to CI

Make It a Habit, Not a Hero Moment

I Found an API Key in My Git History. Here's How I Stopped Doing That.

Why this keeps happening

The fix: get it right before your first commit

The actual habit to build

Why Your README Still Sucks (And How I Fixed Mine in 90 Seconds)

Why READMEs are harder than they look

The fix: stop writing the skeleton by hand

Try it

I Built a Free Timestamp Converter That Never Sends Your Data Anywhere

What it does

Why client-side matters here

Try it

Cron Syntax Is a Trap — Here's a Builder That Explains What You're Actually Scheduling

Build it visually, read it in plain English

A quick example

Why it's worth using over guessing

Try it

Stop Guessing: A Free Regex Tester That Actually Explains Your Pattern

What makes it different from "just another regex tester"

A quick example

Why it runs the way it does

Try it

I Built a Free Color Palette Extractor That Never Uploads Your Images

What it does

Why client-side matters here

A quick example

Part of a bigger toolkit

3 Free CSS Generators That'll Save You From Fighting box-shadow, gradient, and border-radius Syntax

1. Box Shadow Generator

2. Gradient Generator

3. Border Radius Generator

Why browser-based tools like these are worth bookmarking

1. Trusting the `alg` Header Too Much