DEV Community: ke jia

I Typed the Same Docker Command Five Times This Week. So I Built a Snippet Manager That Lives in My Terminal

ke jia — Sat, 12 Sep 2026 04:13:37 +0000

Every developer has a drawer of "useful code" scattered across five places:

Browser bookmarks — that Stack Overflow answer with the exact flag
Chat history — the one-liner a coworker sent in Slack three months ago
Old terminals — scroll back 200 lines, it's gone
Project READMEs — findable only if you remember which project
Your brain — a terrible database

By the time you find the snippet again, you've re-typed half of it, guessed the other half, and lost 15 minutes. The snippet is never long. The searching is what costs.

Why existing snippet managers miss

I tried the obvious options:

GUI tools (Raycast, Alfred, ...) — great, but they want your code in a GUI layer, usually an account, often a subscription. I live in the terminal 90% of the day and I don't want to leave it.
Web snippet sites — pasting internal code into a public service is a non-starter. Some of my "snippets" contain internal hostnames and tokens.
IDE snippets — scoped per project, per editor, not searchable across projects, and useless from the terminal where most emergency commands actually live.

What I wanted was boring: one local file, zero accounts, everything in the terminal.

So I built snippetx.

Install

npm i -g @wuchunjie/snippetx

~5 KB, zero dependencies, MIT licensed. Your snippets live in a single JSON file at ~/.snippetx/snippets.json. No daemon, no account, no telemetry, no cloud. Close the laptop — your snippets survive.

The six commands

# Save: pipe anything in
echo 'docker ps -a --format "table {{.Names}}  {{.Status}}"' | snippetx add docker-ps bash

# List (optionally filter by name or language)
snippetx list
snippetx list js

# Search across all snippet content
snippetx search retry

# View
snippetx show a1b2c3d4

# Copy to clipboard (macOS) — pipe to clip on Windows
snippetx copy a1b2c3d4 | pbcopy

# Delete
snippetx rm a1b2c3d4

That's the entire API. There is nothing to configure.

A real workflow: the once-a-month emergency command

The snippet I use least often but need most desperately is a Postgres recovery command. Once a quarter something breaks at 11pm and I need it exactly right — no guessing, no Stack Overflow round-trip.

With snippetx:

snippetx search postgres
#   🔹 7f3a9c21  pg-recovery
#      ...pg_ctl -D /var/lib/postgresql/14/main -o "-c config_file=..."...

snippetx copy 7f3a9c21 | pbcopy

Two commands. The exact command, straight into my clipboard, under ten seconds.

Your snippets are just a text file

This is the part I actually care about. ~/.snippetx/snippets.json is plain JSON:

Back it up — copy one file.
Search with your own tools — grep -r "docker" ~/.snippetx/ works as well as any built-in search.
Version it — drop it in your dotfiles repo and your snippet library follows you to every new machine.

One warning before you push: scan first. If any snippet contains a token, a key, or an internal hostname, it doesn't belong in a public repo. I run dotguard over my dotfiles before every push — here's the full GitHub Actions setup.

The bigger picture

snippetx is one of a few small, local-first tools I ship:

snippetx — your code snippets, in your terminal
dotguard — secret scanning for dotfiles and repos
gitpulse — repo health and maintainer pulse
scaffoldx-cli — interactive project scaffolding

All local-first, all zero-dependency, all MIT. If one of these saves you a few minutes, a ko-fi genuinely funds the next tool.

GitHub: github.com/wuchunjie00

What's the one snippet you re-type so often it deserves its own tool? Tell me in the comments.

Stop Pasting Secrets Into the Console: A Secure Debugging Checklist

ke jia — Sat, 05 Sep 2026 06:02:39 +0000

The browser console is where secrets go to be pasted, and the habit is universal: the token from the API response, the key from the environment, the JWT from the request header, pasted into the console to inspect, to decode, to test. The risk is specific and it has two parts. Part one: the console history is stored, and the pasted secret is in it, in the browser profile, on the machine, until the history is cleared, which is the moment the secret becomes a file, and the file is the persistence, and the persistence is the risk. Part two: the decoder website — the third-party service you paste the token into to see the claims — which is a token exfiltration service with a UI, and the token is in their logs the moment you paste, because the paste is the transmission and the transmission is the exfiltration and the exfiltration is the service.

The fix for part one is the habit: the console is for the page's own data, not for your secrets, and the clipboard is the buffer, not the console, because the buffer is the middle and the middle is the safe, and the safe is the habit. The fix for part two is the local decoder: the JWT decoder in the collection decodes the token in your tab, with no transmission, and the claims — including the expiration, which is usually the answer — are on your screen, because the screen is the local and the local is the safe and the safe is the design. The article is the two-part risk, the specific incident shapes — the token in the history, the key in the logs — and the secure debugging checklist that replaces the habit, with the exact steps for the secure version of every debugging move that usually ends in a paste. Stop pasting secrets into the console; decode them where they cannot leave. The checklist is the article; the habit is the point; the point is the security that the browser gives you if you stop giving it to the console.

Security advice has a formatting problem: it arrives as a forty-page whitepaper, a compliance checklist, or a conference talk you will forget by lunch. The version that actually changes behavior is the five-minute version: the specific thing, the specific risk, the specific fix, in an order you can execute today. That is what this is. No fear-mongering, no imagine-if-your-data-was-stolen. Just the mechanics. the DevTools collection exists because the five-minute version is what a working developer can actually act on, and the sections below are the five-minute version, expanded with the exact commands, the exact checks, and the exact order that makes the difference between a habit and a whitepaper.

The Usage Numbers on the Cards

Each tool card on the collection shows a usage statistic, and the distribution is a map of what developers actually do. The converters and generators with the highest numbers are the ones that solve a daily, low-level pain: parsing a schedule, generating an identifier, converting between formats. The long tail is the specialized tools that solve a rare but critical pain: decoding a token at two in the morning when the API starts rejecting tokens, or diffing two config files to find the one line that broke the deploy. The pattern is the same as in every toolkit: a few tools carry most of the weight, and the rest are insurance. The collection is built for both halves of that distribution, because the insurance is only worth it if it is there in the moment it is needed. The usage numbers are the only analytics the collection has, and they are displayed next to the tools they describe, which is the honest version of a dashboard: the data is right there, with the thing it measures, and nobody has to ask for the report. The report is the page.

The Privacy Argument: Your Data Never Leaves the Tab

The strongest feature of the collection is the one you never see: nothing is transmitted. Every conversion, generation, and inspection happens in your browser, on the page, with no server round trip. That matters most for the tools that handle sensitive input. The token decoder is the obvious example — you are pasting a live token, and a third-party decoder website is a token exfiltration service with a UI. In the local version, the token is decoded in your tab and stays there. The encoded-blob and hash tools are the same story: the input is processed client-side, and the only place your data exists is your machine. For a developer, this tool does not send my data anywhere is not a nice-to-have. It is the difference between a tool and a trust decision, and the collection was built so the trust decision is a one-time yes, made once, by reading the source, which is short enough to actually read. After that, every use is free of the decision. That is the privacy model in one sentence: decide once, by reading the code, and then never decide again.

GitHub Pages: Hosting That Costs Nothing and Owes Nothing

The collection lives on static hosting, and that is a deliberate infrastructure decision with a specific shape. No server to pay for, no uptime to manage, no scaling to think about, no vendor lock-in beyond the repository itself. The site is static files in a git repository, and the entire operational model is: commit, push, done. When a tool needs a fix, the fix is a pull request, reviewable like any other code. When the collection needs to move, it is a repository, portable by definition. The tradeoff is real — static hosting means no server-side features, no accounts, no personalization — but every one of those absences is a feature in this design. The hosting is boring on purpose, because the boring infrastructure is the part that is still there in five years. The subscription-based tool you loved last year is the cautionary tale: the tool was good, the hosting model was not, and the tool died with the business model. The static page has no business model to die. It has a repository, and the repository is the model.

The Converter Family: When Formats Collide

Half of the collection exists for one specific pain: the moment when the format in front of you is not the format you need. YAML from a config file needs to be JSON for the API. CSV from the spreadsheet needs to be JSON for the script. An encoded blob from an error message needs to be readable. An HTML entities dump from a scraped page needs to be plain text. A chunk of HTML needs to be the text inside it. Each converter is small, instant, and client-side — the data you paste is processed in your browser and never transmitted anywhere. The collection is organized so that when the format collision happens, the tool is one tab away, and the answer to how do I convert this stops being a five-minute search and starts being a five-second paste. The converters are the highest-frequency tools in the collection, and the frequency is the point: the tool you use a hundred times a year is worth more than the tool you use a hundred times in one emergency, even though the emergency feels bigger when it happens.

The Generator Family: The Things You Should Never Type by Hand

The generators cover the values that are correct in exactly one way and painful to produce manually. UUIDs for test data and local development. Strong passwords, where the point is the entropy, not the memorability. QR codes for the URL you are about to hand someone at a demo. Placeholder text for the layout that has to exist before the design can be evaluated. URL slugs for the title you are about to publish, with the punctuation stripped and the casing fixed. Each generator is a small answer to a question that comes up dozens of times a year, and the cost of answering it without a tool is low individually and high in aggregate. The collection treats those small costs as the thing to eliminate. The generators are the least dramatic tools in the set and some of the most used, which is the pattern of the whole collection: the quiet tools carry the load, and the dramatic tools are the insurance you hope you never need but are glad is there.

Pairing the Browser Tools With the CLI Toolkit

The browser collection and the CLI tools cover the same developer day from two angles. In the terminal: the scaffolder generates the project, the secret scanner checks it, the git analytics measure the repository, the snippet manager stores the code that falls out. In the browser: the converters handle the format collisions, the generators produce the values, the inspectors decode the artifacts. The day is one continuous loop of mechanical problems, and the toolkit is the set of small answers to each of them. The two halves are independent — the browser tools do not need the CLI, and the CLI does not need the browser — but the pattern is the same in both: a specific, frequent, mechanical task, answered by a tool that does exactly that and nothing else. Collectively, they are a working theory of what a modern developer's toolkit should look like: small, single-purpose, zero-ceremony, and always available. The theory is not in the tools individually; it is in the set, and the set is the argument. Each tool is a sentence, and the toolkit is the paragraph that makes sense.

The Inspector Family: Reading What You Cannot Parse in Your Head

Inspectors are for the artifacts that are structured but not human-readable at a glance. The Cron expression parser turns a schedule into a sentence and a visualization of when it fires. The JWT decoder splits a token into its header, payload, and signature, and shows you the claims — including the expiration, which is the answer to why is this failing now. The hash generator computes digests for text, which is the verification step after a download. The diff tool highlights the exact lines that differ between two versions of anything. The common thread: the artifact is right there in front of you, but reading it correctly takes a tool. The collection is that tool, for the artifacts every developer meets. The inspectors are the tools that save the most time per use, because the alternative is not a small cost — it is a wrong answer, and the wrong answer in a schedule or a token or a checksum is the kind of error that costs an hour to find. The inspector finds it in five seconds, which is the entire value proposition of the family.

What I Would Add Next, Honestly

Every collection has a backlog, and being honest about it is more useful than pretending the tool is finished. The candidates in order of value: more converter pairs — the remaining config formats are the obvious gaps; a date-time formatter to sit next to the schedule parser; and a language pass, because the site currently ships in one language while the problems it solves are universal. The candidates I am deliberately not doing: accounts, sync, and personalization. Those are the features that would turn a zero-trust tool into a trust decision, and they are the features that would add a server to a serverless site. The backlog is a list of converters and formatters. Everything else is a different product, and a different product is not the point. The honesty is the feature: the roadmap is short enough to read, the non-roadmap is named, and the reason for each no is the same reason the collection exists in the first place — the tool should stay small enough to trust, and every feature that does not serve that constraint is a feature the collection does not have. The absence is the policy.

Why Pure HTML Is a Feature, Not a Limitation

Every tool in the collection is a single HTML file. No framework, no build step, no node_modules, no bundle. The consequence is that the tools are smaller than the README that describes them, they load instantly on any connection, they work in airplane mode, and they will still work when the current JavaScript framework of the moment has been abandoned. There is also a maintenance argument: a pure-HTML tool can be reviewed by anyone in the team, fixed with a text editor, and deployed by pushing a file. The build pipeline for the entire collection is a commit. In a category full of tools that need a runtime version and a package manager to run, the absence of both is not a compromise. It is the product. The tool should be as permanent as the problem it solves, and the problems — convert this, generate that, decode this — are as old as the formats themselves. The formats change slowly. The pure-HTML tools change with them, and nothing else in the stack has to change at all. That permanence is the feature.

14 Tools, One Tab, Zero Install

The collection is fourteen developer tools on a single page: a Cron expression parser, a YAML-to-JSON converter, a URL slug generator, an HTML-to-text converter, a QR code generator, an HTML entities encoder and decoder, a UUID generator, a password generator, a Lorem Ipsum generator, a hash generator for the SHA family, a Base64 encoder and decoder, a JWT decoder, a text diff tool, and a CSV-to-JSON converter. All of them are pure HTML and JavaScript. No install, no extension, no account, no build step. You open the page, you pick a tool, you use it, you close the tab. The design constraint that shaped everything: if a tool needs an install, it will not be used in the moment it is needed, and the moment it is needed is the only moment it matters. Fourteen tools, one tab, zero install — and each one does exactly one job, which is the constraint that makes the collection feel like a drawer of hand tools instead of a software suite. The drawer is the point.

Who It Is For, and Who It Is Not

The collection is for the developer who hits a format problem and wants the answer in five seconds, not a five-minute search. It is for the two-in-the-morning token decode, the conference-room QR code, the config conversion on a flaky connection. It is not for the team that needs shared workspaces, audit logs, and admin controls — that is a different category of product with a different trust model. It is not for the power user who wants a plugin ecosystem or a macro system — the tools are deliberately one-job-each. And it is not a replacement for a real IDE or a real debugger; it is the set of small, standalone answers that sit next to those tools. The right frame is a drawer of hand tools: each one small, each one specific, and the drawer is the point. Knowing who it is not for is as useful as knowing who it is for, because the wrong user does not get a bad experience — they get an experience that is missing the features they came for, and the missing features are the named ones, the deliberate absences. The collection is honest about its edge, and the edge is the design.

The takeaway

That is the five-minute version, and it is executable today. The tool that makes the check automatic: Open https://wuchunjie00.github.io/devtools/, source at https://github.com/wuchunjie00/devtools. The habit that makes it matter: run it before the push, not after the incident. If this saved you from a specific leak, ko-fi.com/wuchunjie keeps the scanner free, and the same npx pattern covers the rest of the toolkit — scaffoldx for clean starts, gitpulse for repository health, snippetx for the code in between. Security is a habit with tooling, not a tooling problem with a habit. The five-minute version above is the habit; the tool is what keeps the habit from costing more than a line of workflow file. Run it this week, not next month. The leaks do not wait for the habit to form.

Measuring 1,000 Repos Taught Me That git blame Was Lying to Me

ke jia — Sat, 05 Sep 2026 06:02:26 +0000

The research project that shaped gitpulse was simple to describe and slow to do: run the same set of measurements across a large number of repositories and look for the patterns that hold. The repositories were a mix of my own projects, client work I had permission to analyze, and public repositories from a range of stacks and team sizes. The results were not a leaderboard — no top repositories, no rankings, no shame — they were a set of distributions, and the distributions are where the surprises were.

Hotspot concentration held across nearly every repository: a small fraction of files carried the majority of the churn, and the fraction was more consistent across repositories than any per-repository metric was, which is the finding that changed the design. Commit patterns correlated with team size more than with team quality: small teams look erratic, large teams look steady, and the middle is where the interesting data is. The branch ratio was the most stable metric in the entire study — teams do not change their shipping process, they change their people, and the history records the people, not the process, which is the finding git blame never shows you, because blame shows the hands and not the process. This article is the summary of what the data said, with the specific distributions and the design decision each one produced. The lying was not in the blame; it was in the question. The right question is the article; the data is the evidence.

I did not set out to build gitpulse. I set out to fix a specific problem, and the tool is the scar tissue from fixing it properly. This is the story in the order it actually happened: the incident, the first attempt that did not work, the constraint that shaped the design, and the decision I would make differently if I were starting over. None of it is polished, because the polished version would be a press release, and I would not trust a press release either. If you are deciding whether to use @wuchunjie/gitpulse, the build story is the most honest document about what you are getting — including the parts that are limitations, which the marketing page would never name.

Pairing gitpulse With dotguard in One Pipeline

A repository has two kinds of health: structural and security, and they are measured by different tools. One tells you whether the code is organized and maintained — hotspots under control, contributors distributed, branches reviewed. The other tells you whether the repository is leaking — secrets in configs, tokens in history, credentials in compose files. Running both in the same weekly pass is a complete repository health check in under a minute, and the outputs are complementary: a hotspot in a config file that the secret scanner also flags is a refactoring task with a security deadline. Two small CLIs, no shared infrastructure, one habit. That is the whole architecture of the pipeline, and it is the kind of architecture that survives because nothing in it needs to be maintained. The weekly pass becomes the meeting the team does not have to schedule: the file is the agenda, the findings are the action items, and the rotation of the week is the follow-up. Infrastructure this small is not a platform. It is a reflex, and reflexes are what teams actually keep.

Contributor Impact: Measuring What Actually Ships

Commit count is the most common contributor metric and the least useful. A person who makes two hundred small commits to one file is not contributing two hundred times more than a person who makes twelve commits that each change a module. The analytics weigh contributions by impact: lines changed across distinct files, churn on hotspots, and the span of the codebase touched. The result is a much better answer to the onboarding question — who owns what — and the succession question — what happens if this person leaves. The tool is not a performance review; anyone who uses it that way is using it wrong. But it is a map of where the institutional knowledge actually lives, which is a map every team should have before it needs it. The impact ranking is that map: the people at the top are the load-bearing walls of the codebase, and knowing which walls they are is not management overhead. It is structural engineering.

When Analytics Are the Wrong Tool

Honesty section: repository analytics are not for every repository. A new project with two weeks of history has no patterns to analyze — the hotspots are noise, the commit shape is just one person working, and the branch ratio is undefined. A solo project where you are the only contributor and you already know the codebase has little to tell you. And a repository where the team will use the output as a performance signal will get a distorted version of the truth, because the data was never collected for that purpose. The right use is a diagnostic: a repository you are inheriting, a repository that feels slower than it should, a repository you are about to present to stakeholders. Use it as a stethoscope, not as a scoreboard. The stethoscope tells you where to listen; the scoreboard tells you who to blame, and the blame is never in the data. Knowing which instrument you are holding is the whole skill, and the wrong instrument, used with confidence, is worse than no instrument at all.

Branch Strategy: The PR-versus-Direct-Push Ratio

How does your team actually ship? The honest answer is in the history, not in the process document. The analytics measure the ratio of changes that arrive via merge — through review — versus changes that land on the branch directly. The number is not moral; direct push is fine for docs, dependencies, and solo work. But the shape of it tells you how much review your code actually gets. A repository where the large majority of commits are direct pushes has a code review process that exists in the wiki, not in the history. The compare flag lets you look at the ratio between two branches, which answers the practical question: is the integration branch cleaner than the trunk, or did the branching experiment produce more direct landings than the mainline? The ratio is a process fact, and process facts are the kind of thing you cannot get from a meeting. The meeting tells you what the process is supposed to be. The history tells you what it is.

CSV Out: Health Reports Without a Dashboard

The tool can export its findings as CSV, and that one flag is the answer to the dashboard question. The standard objection to CLI analytics is that nobody will read the output in a terminal. Fair. So the output becomes a file: a health report, attached to a message, emailed to the team on the first of the month, dropped into a spreadsheet that the tech lead already maintains. No server, no subscription, no infrastructure project. The data leaves your machine only when you decide it should, and the format is one that every tool you already have can open. For most teams, the right analytics infrastructure is a file and a habit, not a platform. The file is the report; the habit is the monthly export and the five-minute read. Everything else — the dashboards, the integrations, the subscriptions — is what you add when the file-and-habit version stops being enough, which for most small teams is never, and for the teams where it is, the CSV is the import format they will thank you for.

Onboarding a New Repo in 60 Seconds

The worst moment in a developer's life is opening a repository they have never seen: no documentation, a multi-year history, and a codebase that looks the same in every folder. The analytics turn that moment into a sixty-second orientation. The hotspots tell you where the action is — start reading there, not at the README. The contributor impact tells you who to ask when the code does not make sense. The branch strategy tells you how changes actually get in, which is the one process fact that documentation never gets right. Inherited projects are the common case, not the exception: new job, new team, acquired codebase, open-source contribution. A tool that compresses the first hour into the first minute pays for itself on the first use. The sixty seconds buy you something rarer than time: a map, so the first day is spent building context instead of stumbling through directories hoping the important file announces itself.

Hotspots: Finding the Technical Debt Magnets

Every codebase has a handful of files that attract change the way a drain attracts water: the config that every feature touches, the utility that every module imports, the model that every migration reshapes. The analytics surface these as file hotspots — the files with the highest change frequency over your chosen period. The value is not the list itself; it is what the list tells you. A hotspot that is growing is a refactoring candidate with a priority attached. A hotspot that is stable is just a busy file. And a new hotspot appearing this month is an early warning that a design decision is about to become a migration project. Refactoring is cheaper when it is scheduled than when it is forced, and the hotspot list is the schedule. Read it monthly, and the debt magnets get addressed while they are still magnets instead of after they become the reason the release slipped.

What Measuring Lots of Repos Taught Me

After running the same set of measurements across a large number of repositories — my own projects, client work, and public repositories from a range of stacks and team sizes — a few patterns held up consistently. Hotspots concentrate: a small fraction of files accounts for the majority of churn in almost every codebase. Commit patterns correlate with team size more than with team health: small teams look erratic, large teams look steady, and the middle is where the interesting data is. And the branch ratio is more stable over time than anyone expects — teams do not really change their shipping process, they change the people. The tool was designed to answer one question per repository. Measuring hundreds of repositories let the data answer a question I had not thought to ask: the shape of a codebase is more determined by its size and its people than by its technology, and the technology shows up mostly in the noise. The design decisions that followed — the default period, the impact weighting, the ratio as a headline metric — are all consequences of those patterns.

Reading a Quarter: The Long View

The monthly view is for the pulse; the quarterly view is for the story. Extend the period to a quarter and you can see the arc of a release: the hotspot that built up through the quarter, the contributor who carried the middle two months, the week where the commit pattern broke. That view is where hiring and attrition show up. A new contributor ramping is visible as a growing impact curve. A person leaving is visible as a curve going flat, often weeks before the announcement. And a release that was supposed to be a sprint shows up as a commit pattern that never recovered. None of this requires a dashboard or a database. It is version control history, which you already have, read by a tool that knows which questions to ask. The quarter is the right window for most organizational questions, because a month is noise and a year is archaeology. A quarter is a story with a beginning and an end, and the report reads it for you.

The 30-Second Report

Run the tool with no arguments in a repository and you get the current month, summarized: the hot files, the commit shape, the branch behavior, the top contributors by impact rather than commit count. Thirty seconds from typing the command to having a picture of the repository that the log would take an hour to assemble by hand. The design goal was a report you would actually read, which means short enough to fit on a screen and dense enough that each line earns its place. I use it as a standing habit: first command of the week in any repository I am active in, the same way some developers start with status. The habit is the point. A report that takes ten minutes to generate gets run once a quarter. A report that takes thirty seconds gets run every Monday. The frequency is the feature, because the value of repository analytics is in the delta — what changed since last week — and the delta is only visible if you look often enough to see it move.

Commit Patterns and the Burnout Signal

Commits have a rhythm, and the rhythm is a health metric. The analytics look at when commits happen — by hour, by day of week, by streak — and the pattern is more honest than any survey. A team that commits steadily on weekdays is one kind of team. A team whose commits spike on Friday nights and Saturday mornings is another, and the difference is visible in the data without asking a single person how they are doing. I am not saying commit timing equals wellbeing; it is a signal, not a verdict. But it is a signal that a manager who only looks at velocity will never see, and it is exactly the kind of information that is cheap to collect and expensive to guess at. The right use is the trend, not the snapshot: one busy weekend is a fact, four busy weekends in a row is a pattern, and the pattern is the conversation worth having, had with data instead of with hunches, before the hunches become resignations.

The takeaway

That is the version of events, unedited. If you are reading it to decide whether to use @wuchunjie/gitpulse, the most useful paragraph is the one about the constraint that shaped the design — that is where the tool's character comes from, and character is what you are actually adopting when you adopt a tool. The repository at https://github.com/wuchunjie00/gitpulse has the code, the issues, and the discussions; the fastest way to vote with your hands is npx @wuchunjie/gitpulse. And if the story made you want to see the rest — how dotguard, gitpulse, and snippetx came out of the same habit — each of them has its own build story. ko-fi.com/wuchunjie if any of it was useful. The stories are the documentation that survives, because people remember the story and forget the feature list.

Find the 10 People Who Actually Maintain Your Monorepo (One Command)

ke jia — Sat, 05 Sep 2026 06:01:28 +0000

The question who actually maintains this codebase has a wrong answer that everyone gives and a right answer that takes one command. The wrong answer is the org chart: the team that owns the service, the people in the channel, the names in the ownership file. The right answer is in the git history, and it is not the commit count — it is the impact, which is what gitpulse measures: lines changed across distinct files, weighted by whether the files are hotspots, because a person who touches the debt magnets carries more of the codebase than a person who touches the leaves.

Run the command with a quarterly period and the output is a ranking that answers three questions at once. Who owns the hot files — the people who touch the debt magnets are the people the debt belongs to, and the debt follows the hands, not the org chart. Who is ramping — the new contributor whose impact curve is climbing is the person to pair with, not the person to assign a ticket to. And who is about to become a single point of failure — the person whose impact curve is flat while their commit count is high is doing a lot of small work in one place, and that place is now their name. The command is the same one; the reading is the skill, and this article teaches the reading, with the exact output shapes and the exact questions each shape answers. The map is the point; the command is how you get it.

I have written a lot of gitpulse content, but this is the one that answers the question people actually ask: how do you actually use it, step by step, from zero? No theory, no marketing. Just the commands, the output, and the decisions you will face along the way. If you have been meaning to try @wuchunjie/gitpulse and kept putting it off because the documentation felt like a commitment, this is the version that fits in one sitting. Git analytics in your terminal: file hotspots, commit patterns, branch strategy, contributor impact. — and everything below is what that actually looks like in practice, with the exact outputs you will see and the exact moments where the workflow forks.

What git log Can't Tell You

The log answers one question: who changed what, and when. It is a great question, and it is not the question. The question that actually predicts trouble is: where is the codebase accumulating damage? A file that changes forty-seven times a month is a hotspot no matter how clean each individual commit looks. A team whose commits cluster on late weekend hours is a team that is running hot no matter how green the pipeline is. The log shows you the events; the analytics show you the patterns underneath the events. That difference is the difference between a log and an analysis, and it is the reason a tool that reads your entire history and summarizes the shape of it is a different category of instrument from the version control system itself. The events are facts; the shape is the information. This article is about the shape, and about how to get it in thirty seconds instead of an afternoon of log-reading.

What Measuring Lots of Repos Taught Me

Contributor Impact: Measuring What Actually Ships

Onboarding a New Repo in 60 Seconds

Hotspots: Finding the Technical Debt Magnets

The 30-Second Report

When Analytics Are the Wrong Tool

Pairing gitpulse With dotguard in One Pipeline

The 2>/dev/null Bug: How I Learned to Test Where Users Are

A recent release was a fix for a bug that had been silently present for three months: a shell redirect that is fine on Linux and macOS and quietly wrong on Windows, where stderr handling behaves differently. The tool ran, produced output, and the bug only showed up as missing data for a subset of users on a subset of platforms. The lesson is not that I made a mistake. The lesson is that a CLI tool's test matrix has to include the platform where your users are, not the platform where you are. Three months of silent wrongness is longer than most bugs survive in a well-tested product, and the fix was one line. But finding it required a user report, not a test. That gap — between the platforms you test on and the platforms your users run on — is the most expensive gap in a cross-platform CLI, and it is the one that never shows up in your own usage because your machine is the one platform that always works. The fix was a line. The lesson is a test matrix.

Reading a Quarter: The Long View

Commit Patterns and the Burnout Signal

The takeaway

That is the whole workflow. npx @wuchunjie/gitpulse gets you started, and the repository at https://github.com/wuchunjie00/gitpulse has the full reference when you need it. If this saved you an hour, a coffee at ko-fi.com/wuchunjie keeps the tools free. And if you want the rest of the toolkit — dotguard for secret scanning, gitpulse for repository analytics, snippetx for snippets — the same npx pattern works for all of them. One command each, zero dependencies each, and a terminal that finally does the mechanical part of the job. The tutorial ends here; the habit starts now.

Wire Dotguard Into GitHub Actions: A Full-Repo Secret Scan in One YAML Block

ke jia — Sat, 05 Sep 2026 06:01:19 +0000

Here is the entire integration, before the walkthrough: one step in your workflow file, a run line that calls npx @wuchunjie/dotguard, and a build that fails when a secret is found. That is the whole design, and the rest of this article is the details that make it real. How to choose the workflow trigger — the pull request event is the right one, because the secret should never reach the default branch, and a push trigger on the main branch is a second net for the direct pushes that slip through. How to read the JSON report when the scan finds something, file by file, line by line, so the fix is a two-minute job instead of a forensic exercise.

How to handle the first false positive without disabling the check — the answer is a documented exception, not a muted pipeline, because a muted pipeline is a scanner that is no longer a scanner. And the part everyone skips: running the scan once, before the integration, on the current state of the repository, so the first CI run is not a list of historical findings you did not cause. The setup takes twenty minutes, which is the longest part of the whole project. The protection is permanent, which is the shortest part. The article is the twenty minutes, step by step, with the exact YAML, the exact report, and the exact exceptions file for when the first false positive arrives, which it will.

I have written a lot of dotguard content, but this is the one that answers the question people actually ask: how do you actually use it, step by step, from zero? No theory, no marketing. Just the commands, the output, and the decisions you will face along the way. If you have been meaning to try @wuchunjie/dotguard and kept putting it off because the documentation felt like a commitment, this is the version that fits in one sitting. Scan .env files, config files, and source code for exposed secrets. Zero dependencies, JSON reports, 1000+ files in seconds. — and everything below is what that actually looks like in practice, with the exact outputs you will see and the exact moments where the workflow forks.

The Cost of a Leaked Key, Quantified

The numbers on public cloud incidents are uncomfortable in a specific way: they are all larger than the annual budget of the team that leaked the key. Compromised cloud credentials have produced bills in the hundreds of thousands of dollars in a single weekend. Leaked repository tokens have been used to push malicious code into downstream packages that millions of installs then inherit. Leaked database passwords have emptied tables into the clear. The economics are one-directional: the cost of a scan is a line of workflow file and a few seconds of CPU; the cost of a miss is measured in six figures and a postmortem you will give in the morning with your team in the room. The asymmetry is the entire argument for running the scanner by default, on every push, in every repository, whether or not you think you have secrets in it. The repositories that are sure they have no secrets are the ones that have never checked, and the check is the only difference between those two statements.

How the Scan Actually Works

The scanner looks for the patterns that real secrets actually take. Cloud provider keys start with a known prefix, Git tokens start with a known prefix, messaging platform tokens have a known shape, payment processor live keys have a known prefix, and web tokens start with a known base64 header. It also checks for high-entropy strings assigned to suspicious variable names — password, token, secret, key — because the values do not always follow the format, but variable names are a reliable signal. The scan covers environment files, config files, and source code, and it reports the file, the line, and the matched pattern so a human can verify in seconds rather than minutes. It is deliberately a detection tool, not a verdict tool: it finds candidates, a human confirms, and the key gets rotated either way. That division of labor is what keeps false positives from becoming noise fatigue.

Secrets Hide in Unlikely Places

The environment file is where people look, and it is where secrets are least well hidden. The real distribution is wider: a database URL inside a container compose file, an API key in a YAML config under a deploy directory, a webhook token in a JSON file checked in for one test, a token pasted into a README as a working example. The scanner covers source code, not just dotfiles, precisely because the pattern of where secrets actually live is messier than the pattern of where people think they live. If your security review only opens environment files, you are reviewing one out of five places. The scanner's job is to make the review exhaustive by making it automatic, and the exhaustive part is the whole value. The surprising findings — the ones in files nobody would call secret files — are the ones that justify the tool, because they are the ones no checklist would ever reach. A checklist asks about secrets; the scanner asks about every file, which is a different and better question.

Scanning the Worktree, and the History Behind It

The scanner covers what is on disk: the environment files, the config files, the source in your working tree. That catches the obvious case — the file you just created and are about to commit. For the subtler case, the secret that is already in history, you combine it with the version control system: find the files that ever contained the pattern, then scan them. A committed secret does not stop being a secret when it is deleted from the current branch; it lives in every clone, every fork, and every mirror. The honest workflow is two steps: scan the present automatically, and audit the past with the same rules applied to the files that history touched. Detection is a habit, and habits are easier to keep when the tooling is small enough to run by reflex. The present scan is the reflex; the past audit is the quarterly deep clean, and both use the same rules, which is what makes the pair coherent instead of two unrelated chores.

Writing the Detection Rules Is a Window Into Developer Habits

The detection rule set is a fossil record of how developers actually handle secrets. The cloud provider rule catches the most leaks by volume, which says something about how much infrastructure runs on a single provider. The web-token rule catches a specific habit: developers pasting a full token into code to debug one endpoint, then forgetting it is there. The high-entropy rule exists because a surprising number of teams generate strong keys and store them with weak discipline — random value, obvious variable name, plaintext file. Building the rules taught me that secret leaks are not a knowledge problem; everyone knows the environment file should not be committed. They are a friction problem. The right thing is slow, the wrong thing is fast, and the scanner removes the friction from the right thing by making the check automatic. Every rule in the set is a documented instance of the friction, and the rule set is a map of where the friction lives in a codebase.

The JSON Report That CI Can Actually Use

A security tool is only as good as its integration surface, and the scanner's is a JSON report. Run it with the report flag and you get a machine-readable list of every finding: file, line, rule, severity. Exit codes are meaningful, so a pipeline can fail the build on any finding without parsing colored terminal output. That design decision pays off in the boring way: the tool fits into CI or a local pre-push script with zero glue code. When the report is data instead of text, other tools can consume it — a dashboard, a chat alert, a compliance export. Security tooling that cannot be integrated is a demo, not infrastructure. The JSON report is the part of the design that turns a one-person tool into a team habit, and it costs nothing to use: the same command, one extra flag, and the output becomes something the rest of the system can act on.

Monorepos, Home Directories, and the Recursive Flag

The scanner assumes your secrets live in one project, and then breaks that assumption on purpose. The path flag lets you point it at a subdirectory — scan just the deploy configs, or just one service in the tree. The recursive flag lets you do the opposite: point it at your projects directory and audit everything you have ever written, including the old side projects you forgot about. That last use is the one that pays for itself. Leaks do not respect project boundaries; the forgotten demo repository from a few years ago is a live credential the moment someone finds it. A scanner that can sweep an entire directory tree in seconds turns auditing all your code from a month-long project into a coffee break. The monorepo use is the inverse: one command covers every service, so the scan cost does not grow with the organization. Either direction, the same principle: the scan should be cheap enough to run often, and running it often is what catches the leak while it is still cheap to fix.

Rotation Beats Detection, Every Time

There is a comfortable misconception that finding a secret is the win. It is not. The win is the key that no longer works. A detected secret that stays valid is a secret that is still leaking; the only difference is that now you know about it, which is a strange kind of liability. The workflow that matters is: scan, confirm, rotate, and then scan again to confirm the rotation happened and the old value is gone from the working tree or accepted as a known dead value. Rotation is boring, it touches other teams, and it is the step everyone skips. A detection tool that makes rotation feel like a natural next step — by giving you the exact file and line, so the fix is a two-minute job — is doing more than pattern matching. The finding is a ticket, and the ticket's definition of done is the rotated key, not the closed alert. Designing the tool around that definition of done is what separates a scanner from a security workflow.

What Zero Dependencies Buys You in a Security Tool

A security tool has a special trust problem: you are asking it to read your most sensitive files. The natural question is what the tool itself trusts. For this one, the answer is nothing. No dependencies, no network calls, no telemetry, no update daemon. It reads files, matches patterns, and writes a report. That matters in the places where security tooling gets blocked: restricted CI runners, air-gapped builds, compliance environments that require an audit of every third-party package in the pipeline. A single-file scanner with zero dependencies is auditable in an afternoon by a security reviewer who would never approve a forty-package tree. In security, small is not a feature. Small is the product. The auditability is the trust model: you can read the whole thing, you can verify what it matches, and you can be confident that the thing reading your secrets is not also phoning home with them. That confidence is not a nice property of the design; it is the design.

The Team-Wide Hook: Distributing the Habit

Personal hooks die with the person who set them up. The pattern that actually works is distribution: put the scan in a hook that lives in the repository itself, committed to version control, so every clone gets the behavior automatically. A new developer clones the repository, runs their first command, and the scanner is already there. Nobody has to be told, nobody has to remember, and the behavior cannot be forgotten because it is part of the repository. This is the difference between a tool and a practice: a tool is what one person runs, a practice is what the repository does to everyone. The scanner is small enough that the distributed version costs nothing to maintain — one file, one command, zero configuration — which is exactly the size at which a team habit becomes cheaper than the individual habit it replaces. The repository becomes the enforcer, and enforcement by repository is the only enforcement that survives turnover.

False Positives Are the Real Cost of a Scanner

Every secret scanner has to make a tradeoff: miss a real key, or flag a false one. The scanner leans toward flagging, and the price is occasional false positives — an encoded blob that looks like a key, a test fixture with a fake credential, a documentation example that uses a real-looking prefix. That is why the output includes the file, the line, and the matched rule: the cost of verifying a finding should be five seconds, not a forensic exercise. A scanner with zero false positives that also misses real keys is a liability, not a tool. Budget a minute per finding, verify, rotate if it is real, and note the known test values so the team stops re-checking them. The loop is the product. Over time the false-positive list becomes its own artifact — a record of the places in the codebase that look like secrets and are not, which is useful information in its own right, because it maps the codebase's sensitive-looking surfaces.

The takeaway

That is the whole workflow. npx @wuchunjie/dotguard gets you started, and the repository at https://github.com/wuchunjie00/dotguard has the full reference when you need it. If this saved you an hour, a coffee at ko-fi.com/wuchunjie keeps the tools free. And if you want the rest of the toolkit — dotguard for secret scanning, gitpulse for repository analytics, snippetx for snippets — the same npx pattern works for all of them. One command each, zero dependencies each, and a terminal that finally does the mechanical part of the job. The tutorial ends here; the habit starts now.

Vite create vs ScaffoldX: Do You Really Need a Framework Chooser?

ke jia — Sat, 05 Sep 2026 05:59:54 +0000

You can create a Vite project without ScaffoldX — that is not the claim. The claim is narrower: Vite's create command asks you a sequence of questions and hands you a framework starter, while ScaffoldX hands you a framework starter plus the opinions that come after the framework — TypeScript strictness, linting, formatting, git initialization, and the folder structure that survives contact with a team. To test it, I did both, side by side, for the same React + TypeScript project, and I timed every step including the follow-up installs that the minimal starter does not include.

The raw scaffold time difference is small; the time-to-first-clean-commit difference is not, because the minimal path spends its savings on a follow-up session of config work that the ScaffoldX path did while you were naming the project. There are situations where the minimal path is right — you want the bare tree, you have your own config pipeline, you are inside an existing monorepo toolchain. This article covers those situations honestly, with the exact commands for each path, and then covers the situations where the extra thirty seconds buys you the next thirty minutes. The decision is not about the framework. It is about what happens in the hour after the framework is installed.

The ScaffoldX-versus-something question comes up more than it should, and the usual answer is a features table that says nothing about your actual situation. So I did the comparison the useful way: same workload, same data, both tools, and I wrote down what actually happened — the output, the time, the false positives, the moments where one of them quietly did the right thing and the other did not. This is not a marketing document for either side. It is a decision guide: if your situation is A, use X; if it is B, use scaffoldx-cli. The only command you need to start is npx scaffoldx-cli, and the rest of the article is the evidence for the decision, laid out so you can skip to the section that matches your case.

Before and After: The Setup Math

Here is the honest before-and-after for a typical React and TypeScript project. Before: create the folder, initialize the package, install the framework and its dependencies, install the bundler and its plugin, install TypeScript and the type definitions, write the compiler config, install and configure the stylesheet framework, add linting, add formatting, create the source directory, and fix the entry point. Thirty to forty minutes, and it varies with how bad the day is. After: one command, thirty seconds, and the result is the same tree with working configs. The time math is not even close — but the real win is consistency. Every project started this way has the same structure and the same quality floor, which makes every future project easier to navigate, including the ones that were not scaffolded. The template is a standard, and standards are what make a portfolio of projects feel like one codebase.

Zero Dependencies: The Design Constraint That Changed Everything

The entire CLI is a single file with zero runtime dependencies. That was a deliberate constraint, and it shows up in every property of the tool. Install is instant because there is nothing to install; npx fetches one file. There is no transitive dependency tree to audit, no supply-chain surface to worry about, and no version conflicts with your system Node. It also means the tool keeps working years from now, when half of the packages it might have depended on have moved on. When you are generating the skeleton of a project, the tool itself should be the least surprising part of the stack. A scaffolder that depends on forty packages is doing your project a disservice before you have written a line of code. Small is not a limitation here; small is the feature, and every other design decision follows from it.

What the 12 Templates Actually Include

The template list is the product, and the details matter more than the count. The React template is Vite 6 with TypeScript and Tailwind v4. The Next.js template uses the App Router with strict TypeScript. The Express API template comes with Prisma, Zod validation, and JWT auth already wired together. The FastAPI template is async Python with Pydantic models and pytest ready to run. There is also a Chrome Extension template on Manifest V3 with popup and background, a CLI tool template built on Commander and Chalk, a landing page with a responsive layout and a CTA section, a Discord bot on discord.js v14 with slash commands, an Electron app, a plain Python script with argparse and logging, a vanilla HTML/CSS starter, and an empty strict-TypeScript project for when you want a bare floor. Twelve starting points covers most of what a JavaScript or Python developer will spin up, and each one is a complete, working project rather than a skeleton with holes.

The 30-Minute Tax You Pay on Every New Project

Every new project starts the same way: create the folder, write package.json, install the framework, add TypeScript, configure the bundler, add linting, set up the folder structure. Done carefully, that takes thirty to forty-five minutes. Done from memory, it takes the same amount of time plus a dozen detours through documentation. Multiply that by every prototype, side project, and client job you start, and the boilerplate tax becomes one of the largest invisible costs in a developer's year. The fix is not to memorize the setup better. The fix is to stop doing the setup at all. If the starting point is reproducible in one command, thirty minutes becomes thirty seconds, and the only thing left to think about is the actual problem you are trying to solve. That is the entire argument for a scaffolder, and it is the argument every section below is built on.

Every Template Compiles. That Is the Whole Quality Bar.

Most scaffolds are written once and never run again. The templates drift: a dependency version bumps and the build breaks, a config file references a file that was renamed, and the next person who runs the command gets a broken start. The standard set for ScaffoldX is simple: every template must compile and run before it ships, and it gets re-verified when the CLI is updated. A starter that does not build is worse than no starter, because it costs you an hour of debugging before you realize the problem was the skeleton, not your code. Boring guarantees beat clever features, especially in a tool whose only job is to get you to a working state fast. If a template ever fails that bar, the fix is to the template, not to a warning message telling the user to deal with it.

When a Scaffolder Is the Wrong Tool

Honesty section: a scaffolder is not for everything. If you are joining an existing codebase with its own conventions, do not scaffold a new project next to it. If your stack is unusual enough that no template matches, a half-right template is a trap — you will spend the saved time un-scaffolding. And for a serious production system with an established team, the value of a new skeleton is mostly in the configs, not the code. The tool is aimed at the moment between an idea and the first real decision: prototypes, side projects, client work, and new internal tools. Use it there and it earns its keep. Use it everywhere and you will be fighting the template. Knowing the edge of the tool is part of using it well, and the edge is exactly the line between starting something new and continuing something that exists.

npx First: The Zero-Install Workflow

You do not need to install the CLI globally. Running it via npx executes the current version on demand, which makes it perfect for CI, containers, and shared machines where global installs are forbidden. It also means the version you run is always the one you asked for, not whatever happened to be in your global node_modules from last year. For one-off scaffolding — a prototype for a meeting, a demo for a client — a zero-install tool removes the last friction: you do not even have to decide whether a tool is worth installing permanently. Run it, generate the project, move on. The workflow is designed so the tool is a verb, not a possession: you do it, rather than you having it.

TypeScript Strict Mode by Default

There is a version of TypeScript setup that feels generous: implicit any allowed, strict off, a few suppression comments as training wheels. It compiles fast and feels productive, and then six months later the codebase is full of any-shaped holes and a strict-mode migration is a quarter-long project. The scaffolder takes the other path: wherever TypeScript is in the template, it is strict from the first file. The small cost — a bit more ceremony on day one — buys you a codebase where the compiler catches real bugs for free, forever. Defaults are a design decision with a decade-long half-life, and strict is the default that still makes sense when the project has fifty thousand lines. The alternative is paying the migration cost later, with more code and less context, which is always the more expensive way to make the same change.

Auto git init and Best-Practice Configs

New projects quietly inherit their quality from the first commit. The scaffolder runs git init for you, so history starts clean from second one instead of after an hour of messy first work. It also writes the configurations that are easy to forget in the rush: an ESLint config, a Prettier config, and a tsconfig in strict mode wherever TypeScript is involved. That last part matters more than it looks. Teams that start in strict mode never have to live through the painful migration later, when every function signature is a mine. The scaffolder is doing two jobs at once: saving setup time, and setting the quality floor before the codebase has momentum in the wrong direction. Defaults are a design decision with a decade-long half-life, and these are defaults that still make sense at scale.

The Express Template, in Detail

The Express API template is the one reached for most, so it gets the most care. You get a Prisma schema with a migration already run, Zod schemas for request validation so bad input never reaches the handlers, and JWT auth with a working login and a protected-route example. The folder layout is boring on purpose: routes, controllers, services, models, each in its own place. When you start an internal API or the backend for a small product, the distance from running the command to a health endpoint that returns 200 should be measured in seconds, not setup afternoons. That is the bar this template is held to, and it is the reason the template list is short and specific instead of long and vague. Every template is an opinion about what a project of that type should look like on day one, and the Express one is the most complete expression of the idea.

Where It Fits in a Bigger Toolkit

Scaffolding is the start of a pipeline, not the end. In the workflow that surrounds it, the sequence is: generate the project, scan it for secrets before the first push so the habit exists from day one, and once the repository has a month of history, measure whether the structure you started with is holding up or whether files are turning into hotspots. The snippets that fall out of the project go into a local snippet store, so the next project can start from more than a template. Four small tools, each doing one job, connected by the same habit: keep the mechanical parts of development mechanical. The scaffolder is the first link in that chain, and the chain is the point. No single tool in the set is interesting without the others, and together they cover the day from idea to shipped code without a single manual setup step.

The takeaway

The short version: both options are good, and the right one depends on a detail of your situation that only you know. Run npx scaffoldx-cli on a throwaway repository, run the other option on the same repository, and let the output argue. If this comparison saved you from a wrong decision, the repository at https://github.com/wuchunjie00/scaffoldx is where the tool lives, and ko-fi.com/wuchunjie is where the coffee lives. The rest of the toolkit — scaffoldx, dotguard, gitpulse, snippetx — follows the same one-command pattern, so the comparison habit generalizes: same workload, same data, let the output decide.

What Your Browser DevTools Reveal About Your Privacy (Check These 6 Things)

ke jia — Sat, 05 Sep 2026 05:56:44 +0000

Six checks you can do in your own browser in ten minutes, with the tool from the collection at the check that needs one. Check one: the cookies — the Application tab, the list of what is tracking you on the sites you visit, and the specific cookies that are third-party, because the third-party is the tracker and the tracker is the cookie and the cookie is in the tab. Check two: the localStorage — the same tab, the data the sites keep when you leave, and the tokens that are sitting there, because the token is the session and the session is the identity and the identity is in the storage. Check three: the JWT decoder, on the tokens you find in check two — decode them locally, read the claims, check the expiration, and the answer to how long is this session valid is in the payload, which is the check the browser cannot do alone and the collection can, because the decoder is the tool and the tool is the check.

Check four: the network tab on a fresh load — the requests the page makes before you interact, and the third-party domains in the list, because the pre-interaction request is the tracking and the tracking is the list and the list is the tab. Check five: the hash generator, on the files you download — the verification that the download is what the site says it is, because the verification is the hash and the hash is the check and the check is the tool. Check six: the diff tool, on the terms of service you signed up to and the terms of service you signed up to a year ago — the changes that were made while you were not reading, because the change is the diff and the diff is the tool and the tool is the check. Six checks, ten minutes, and the specific answer each one gives you, with the exact tab and the exact field for each check, because the check is the article and the answer is the point, and the point is the privacy that the browser shows you if you know which tab to open and which field to read.

The Usage Numbers on the Cards

What I Would Add Next, Honestly

Why Pure HTML Is a Feature, Not a Limitation

The Privacy Argument: Your Data Never Leaves the Tab

14 Tools, One Tab, Zero Install

Offline-First as a Feature, Not an Absence

The tools work without a network connection, and that is the most underrated property in the collection. Airplane mode: the converters still convert. A flaky office connection: the hash generator still hashes. A conference hall with no signal: the diff tool still diffs. The practical moments are specific and real — the deploy that is failing on a train, the token that needs decoding in a meeting room where the Wi-Fi is a joke, the config that needs converting while the VPN is down. An online-only tool is a tool that is unavailable exactly when the network is the thing that is broken. Offline-first is not a fallback mode. It is the difference between a tool that is always available and a tool that is available when the internet agrees. The property costs nothing to build — it is a consequence of the pure-HTML design — and it shows up in the moments that matter most, which are the moments when everything else in the stack is unavailable and the one thing you need is the small tool that does not need the network to be the thing you need. The offline tool is the last tool standing, and that is exactly where you want it.

The Generator Family: The Things You Should Never Type by Hand

The Converter Family: When Formats Collide

The Search Bar Is Load-Bearing

The collection has a client-side search bar that filters the fourteen tool cards by name and description, and it is doing more work than it looks. In a fourteen-tool collection, the failure mode is not: the tool does not exist. It is: I do not remember the exact name, and I do not remember which of the three converters it was. The search bar turns that failure into a two-word query: yaml, hash, qr. The implementation is a few lines of JavaScript that filter the page, which is exactly the kind of feature that a framework-based site would treat as a component and a pure-HTML site treats as a paragraph of code. Small features, done without infrastructure, are the signature of the design: every line of the site earns its place, and the search bar is the line that earns the most, because it is the difference between finding the tool in two seconds and not finding it at all. The search is the index of the drawer, and a drawer without an index is a pile. The bar is the difference.

Who It Is For, and Who It Is Not

Pairing the Browser Tools With the CLI Toolkit

The takeaway

Zero Install, Zero Tracking: How I Ship DevTools That Work Offline

ke jia — Sat, 05 Sep 2026 05:56:38 +0000

The privacy claim of the collection is verifiable, and this article is the verification. Claim one: no analytics, no tracking pixels, no third-party scripts — the page source is the proof, and the article shows the source, which is HTML and a few lines of JavaScript, with no network calls after the load, because the absence is the proof and the proof is the source. Claim two: the tools process data client-side — the converters, the generators, the inspectors, all of them run in the page, and the proof is the network tab, which shows one request: the page itself, because the one request is the whole network activity, and the whole network activity is the claim.

Claim three: the site works offline — the proof is airplane mode, and the article is the walkthrough of the offline test, tool by tool, because the test is the claim and the claim is the design. The design decisions that produce the three claims: pure HTML, no framework, no CDN, no build step that injects a tracker, because the build step is the injection and the injection is the tracker and the tracker is the claim that the design refuses. The tradeoffs are named honestly: no analytics means no usage data, which means the roadmap is from feedback, not from a dashboard; no server means no personalization, which is a feature, not a gap, because the personalization is the server and the server is the trust and the trust is the claim the design refuses. The article is the claims, the proofs, and the tradeoffs — the privacy argument, verified instead of asserted, because the verified claim is the claim you can check, and the check is the article, and the article is the verification, and the verification is the point.

I did not set out to build the DevTools collection. I set out to fix a specific problem, and the tool is the scar tissue from fixing it properly. This is the story in the order it actually happened: the incident, the first attempt that did not work, the constraint that shaped the design, and the decision I would make differently if I were starting over. None of it is polished, because the polished version would be a press release, and I would not trust a press release either. If you are deciding whether to use devtools, the build story is the most honest document about what you are getting — including the parts that are limitations, which the marketing page would never name.

The Generator Family: The Things You Should Never Type by Hand

What I Would Add Next, Honestly

Pairing the Browser Tools With the CLI Toolkit

14 Tools, One Tab, Zero Install

The Inspector Family: Reading What You Cannot Parse in Your Head

The Search Bar Is Load-Bearing

Who It Is For, and Who It Is Not

The Converter Family: When Formats Collide

The Usage Numbers on the Cards

Offline-First as a Feature, Not an Absence

The Privacy Argument: Your Data Never Leaves the Tab

The takeaway

That is the version of events, unedited. If you are reading it to decide whether to use devtools, the most useful paragraph is the one about the constraint that shaped the design — that is where the tool's character comes from, and character is what you are actually adopting when you adopt a tool. The repository at https://github.com/wuchunjie00/devtools has the code, the issues, and the discussions; the fastest way to vote with your hands is Open https://wuchunjie00.github.io/devtools/. And if the story made you want to see the rest — how dotguard, gitpulse, and snippetx came out of the same habit — each of them has its own build story. ko-fi.com/wuchunjie if any of it was useful. The stories are the documentation that survives, because people remember the story and forget the feature list.

Why I Publish Developer Tools on GitHub Pages Instead of npm

ke jia — Sat, 05 Sep 2026 05:55:47 +0000

The question is why publish developer tools as a website instead of an npm package, and the answer is a list of constraints that npm does not satisfy and a website does. Constraint one: the user is not a Node developer at the moment of use — the person who needs a Base64 decode at two in the morning is not in a terminal, they are in a browser, and the package manager is not the interface, because the interface is the tab, and the tab is the browser, and the browser is where the person is. Constraint two: the tool has no install cost and no version — a pure-HTML page is always the latest, because there is nothing to update, and the versioning is the problem the website does not have, because the website is the version and the version is the page.

Constraint three: the distribution is the URL — a website is shareable in a way a package name is not, because the URL is the share and the share is the adoption, and the adoption is the point. Constraint four: the trust model — a page that does what it says on the page is auditable by opening it, and the source is in the repository, and the repository is the audit, because the audit is the source and the source is the page. The article is the four constraints, the counter-arguments — npm has the ecosystem, the versioning, the CI — and the cases where npm is the right answer and the website is not, because the honest story names the cases where the other distribution wins, and the naming is the point. The collection is the website side, in full, and the CLI toolkit is the npm side, in full — and the argument is why both exist, because the tools are the same and the distributions are different, and the distribution is the design, and the design is the story, and the story is the article.

Pairing the Browser Tools With the CLI Toolkit

The Privacy Argument: Your Data Never Leaves the Tab

GitHub Pages: Hosting That Costs Nothing and Owes Nothing

The Converter Family: When Formats Collide

The Usage Numbers on the Cards

14 Tools, One Tab, Zero Install

Why Pure HTML Is a Feature, Not a Limitation

What I Would Add Next, Honestly

The Generator Family: The Things You Should Never Type by Hand

Who It Is For, and Who It Is Not

The Search Bar Is Load-Bearing

The takeaway

Debug a Failing Frontend With Nothing but the Browser: A 12-Step Field Guide

ke jia — Sat, 05 Sep 2026 05:55:34 +0000

A frontend that is failing, and nothing but the browser between you and the cause. Twelve steps, in the order that actually works, with the tool from the collection at the step where it belongs. Step one: the network panel, the request that is failing, the status code, and the first fork in the road — a 5xx is a server problem, a 4xx is a client problem, and the fork determines the next five steps. Step two: the response body, the error message, the field that is wrong, because the error message is the map and the map is read in the body.

Step three: the JWT decoder, when the failure is a 401 and the token is the suspect — decode it locally, check the expiration, check the claims, and the answer to why now is usually in the payload, which is the step the collection exists to make fast. Step four: the Base64 decoder, when the payload is encoded and the error is in the encoding. Step five: the diff tool, when the working version and the failing version differ by a line you cannot see, because the diff is the eye the browser does not have. Step six: the hash generator, when the asset is cached and the hash tells you which version the browser actually loaded. Steps seven through twelve are the browser's own panels — the console, the application tab, the storage, the performance — in the order the failure usually lives, with the specific symptom that sends you to each panel. The collection's role is the steps the browser cannot do alone: the decodings, the diffs, the hashes. Twelve steps, and the specific tool at each one, with the exact symptom-to-step map that makes the guide a field manual instead of a list. The field is the browser; the manual is the article.

I have written a lot of the DevTools collection content, but this is the one that answers the question people actually ask: how do you actually use it, step by step, from zero? No theory, no marketing. Just the commands, the output, and the decisions you will face along the way. If you have been meaning to try devtools and kept putting it off because the documentation felt like a commitment, this is the version that fits in one sitting. 14 pure-HTML developer tools: converters, generators, and inspectors. Zero install, zero tracking, works offline. — and everything below is what that actually looks like in practice, with the exact outputs you will see and the exact moments where the workflow forks.

14 Tools, One Tab, Zero Install

The Generator Family: The Things You Should Never Type by Hand

The Converter Family: When Formats Collide

GitHub Pages: Hosting That Costs Nothing and Owes Nothing

The Privacy Argument: Your Data Never Leaves the Tab

What I Would Add Next, Honestly

Offline-First as a Feature, Not an Absence

Who It Is For, and Who It Is Not

The Search Bar Is Load-Bearing

The Usage Numbers on the Cards

Why Pure HTML Is a Feature, Not a Limitation

The takeaway

That is the whole workflow. Open https://wuchunjie00.github.io/devtools/ gets you started, and the repository at https://github.com/wuchunjie00/devtools has the full reference when you need it. If this saved you an hour, a coffee at ko-fi.com/wuchunjie keeps the tools free. And if you want the rest of the toolkit — dotguard for secret scanning, gitpulse for repository analytics, snippetx for snippets — the same npx pattern works for all of them. One command each, zero dependencies each, and a terminal that finally does the mechanical part of the job. The tutorial ends here; the habit starts now.

9 Chrome DevTools Panels Most Developers Never Open (With Real Use Cases)

ke jia — Sat, 05 Sep 2026 05:54:56 +0000

Nine Chrome DevTools panels that most developers never open, with the real use case for each and the tool from the collection that complements it. Panel one: the Application tab — the storage and the cookies, the use case is the why-is-my-session-not-persisting that the console cannot answer, because the session is in the storage and the storage is in the panel, and the collection's role is the JWT decoder for the token in the storage, because the token is in the storage and the storage is in the panel and the decoder is the tool that reads it. Panel two: the Performance tab — the recording and the flame chart, the use case is the page that is slow and you do not know why, and the collection does not replace it, and the article says so, because the honest list names the panels the collection does not cover, and the naming is the point.

Panel three: the Memory tab — the heap snapshot, the use case is the leak that grows with every render. Panel four: the Security tab — the mixed content and the certificate, the use case is the page that is https but not secure, which is the state that looks secure and is not. Panel five: the Lighthouse tab — the score and the opportunities, the use case is the audit before the launch, because the audit is the score and the score is the panel. Panel six: the Network tab's throttling — the use case is the mobile experience on the desktop, because the desktop is not the phone and the throttling is the phone. Panel seven: the Console's context — the use case is the extension that is interfering with the page, because the extension is in the context and the context is in the console. Panel eight: the Sources tab's breakpoints on XMLHttpRequest — the use case is the request that is built wrong, because the request is built in the source and the source is in the panel. Panel nine: the Rendering tab — the use case is the layout that is wrong in a way the CSS does not show. Nine panels, nine use cases, and the collection at the panel where it helps, with the honest note where it does not, because the list is the map and the map is the article.

Lists are a lazy format, and a lazy list is worse than no list, because it costs you ten minutes and gives you nothing. So this one is built to a standard: every item has what it does, when you would actually use it, and the specific failure it prevents. No filler, no and-more. No item that exists only to pad the count. the DevTools collection is the lens — 14 pure-HTML developer tools: converters, generators, and inspectors. Zero install, zero tracking, works offline. — and the list below is the part you can screenshot and keep. If an item does not save you a specific amount of time or a specific kind of pain, it is not on the list, and the items that are on it are ordered by how often they actually earn their place.

The Generator Family: The Things You Should Never Type by Hand

Offline-First as a Feature, Not an Absence

The Privacy Argument: Your Data Never Leaves the Tab

Why Pure HTML Is a Feature, Not a Limitation

Who It Is For, and Who It Is Not

What I Would Add Next, Honestly

14 Tools, One Tab, Zero Install

The Usage Numbers on the Cards

Pairing the Browser Tools With the CLI Toolkit

The Converter Family: When Formats Collide

The Search Bar Is Load-Bearing

The takeaway

That is the list. Screenshot it, pin it, or just remember the three items you will actually use — that is the honest success metric for a list. The tools behind it: Open https://wuchunjie00.github.io/devtools/, source at https://github.com/wuchunjie00/devtools, and the same npx pattern for the rest of the toolkit. If the list saved you a specific amount of time, ko-fi.com/wuchunjie is a one-click thank-you that keeps every tool free and dependency-free. The next list is already forming, and the items that fail the specific-pain test will not make it. A list that only contains things worth keeping is the only kind of list worth publishing, and that is the standard this one was held to.

All 14 Browser Tools in My Collection, With the Exact Job Each One Does

ke jia — Sat, 05 Sep 2026 05:54:48 +0000

The complete list, no omissions, each tool with its exact job, its input, its output, and the specific moment it is the right tool. One: the Cron expression parser — input is the expression, output is the human sentence and the fire times, the moment is the schedule that is not a sentence, which is every schedule, because the schedule is never a sentence, it is always a pattern of numbers that needs translating. Two: YAML to JSON — the config to the API, the moment is the deploy that needs the config in a different format than the team wrote it in. Three: URL slug generator — the title to the URL, the moment is the publish, because the title is not a URL and the URL is not the title, and the conversion is the step between them.

Four: HTML to text — the page to the words, the moment is the content that needs extracting from the markup. Five: QR code generator — the data to the code, the moment is the demo, because the demo needs the URL on the phone in three seconds, and the three seconds is the window. Six: HTML entities encoder and decoder — the special characters to the entities and back, the moment is the copy-paste that breaks on the ampersand. Seven: UUID generator — the test data to the identifiers, the moment is the test fixture that needs a unique value. Eight: password generator — the requirement to the entropy, the moment is the account that needs a password it does not have to remember. Nine: Lorem Ipsum generator — the layout to the placeholder, the moment is the design review that needs text in the boxes. Ten: hash generator — the file to the digest, the moment is the download that needs verifying. Eleven: Base64 encoder and decoder — the blob to the readable and back, the moment is the error message that is encoded. Twelve: JWT decoder — the token to the claims, the moment is the 401 that needs its expiration. Thirteen: diff tool — the two versions to the changed lines, the moment is the config that broke the deploy. Fourteen: CSV to JSON — the spreadsheet to the data, the moment is the import that needs the table as objects. Fourteen jobs, fourteen tools, and the moment each one is the answer.