Developer Utilities Cheat Sheet

Prompt writing, load testing and camera recording — small but frequent in-browser utilities nearly every developer and operator touches. This page tabulates what each does, when to use it and the pitfalls to avoid.

How It Works

Developers spend a lot of time on small, repetitive transforms and generators: encode/decode, format conversion, string/hash/UUID generation, time math. Such tools earn their keep by being zero-install, instantly available and copy-paste friendly.

Grouping common utilities into one toolbox cuts context-switching between sites and lowers the risk of pasting sensitive data into untrusted third-party pages. A local-first design (data never leaves the browser) is the privacy and security baseline.

When to Use This Table

This table is for finding a small everyday development utility. It groups common tools by purpose — versions and Git, API debugging, JSON and regex handling, encoding conversion, documentation and collaboration — and says what each does and when to reach for it. It is faster than browsing a tool directory blind.

When not to consult it: you are building a CI/CD pipeline, choosing monitoring and logging systems, or evaluating a full development environment. Those are system-level decisions that must fit team size and existing infrastructure, not assemblies of point tools.

Rule of thumb: first ask whether the problem really needs a dedicated tool. One line in DevTools often solves it — formatting JSON, testing a regex, converting a timestamp. Tools earn their place when the operation is repeated or error-prone, not merely possible.

Mind the security boundary: tools on this site run locally in the browser and do not upload your data. Still, confirm how a tool handles input before pasting credentials, API keys or production data containing personal information, and redact privacy-sensitive samples.

Boundaries and Common Pitfalls

Do not hunt for tools for things DevTools already does
JSON formatting, URL encoding, timestamp conversion, regex testing and contrast calculation are all built into Chrome or Firefox DevTools and can be evaluated directly in the console. Adding another tool means one more paste and one more source of risk. The test: only build a tool if you will do the operation more than ten times a year and it is error-prone, such as manual timezone arithmetic.
Still check data flow when using online tools
Tools on this site compute in the browser, but the broader category of online tools includes implementations that upload to a server, so confirm the data flow before pasting sensitive input. A practical test: check whether the page still works offline (local computation) and whether it states that files are not uploaded. For production logs, user data or keys, redact first by replacing emails, phone numbers and tokens — that step costs far less than handling a leak.
Manual version and dependency checks invite systematic errors
When maintaining version numbers, updating dependencies or checking peer compatibility, comparing tables by hand easily misses transitive dependencies and platform differences. The reliable approach is to generate with tools rather than verify by eye: treat the lock file (package-lock.json, pnpm-lock.yaml, uv.lock) as the single source of truth, and diff lock files to see real changes instead of reading version numbers in package.json — the same dependency can be locked to entirely different actual versions in two projects.

How This Relates to Neighbours

Every tool on this site has its own detail page with measured data, which is more specific than this navigation table.

Building CI/CD, choosing an editor or a debugger is environment work, out of scope here.

Understanding a tool’s implementation belongs to that tool’s own documentation; this page only navigates by purpose.

If the goal is finding an alternative to an existing tool, clarify the constraints first — offline requirement, data sensitivity, language support — then consult this table.

Practical Snippet

Key points: (1) most everyday needs — JSON formatting, timestamp conversion, regex testing, URL encoding — can be done in the DevTools console, so look for a tool only when the operation happens more than ten times a year and is error-prone; (2) read dependency versions from the lock file, not package.json ranges, since the same ^4.18.0 can lock to different versions across projects; (3) redact credentials and production data before pasting, even though local tools do not upload; (4) curl piped to jq is faster and scriptable for API debugging, better than a GUI client.

# ① 别忘了 DevTools 就能做（零依赖、零粘贴风险）
# Chrome Console 直接求值：
#   JSON.parse('{"a":1}')                 格式化 JSON
#   new Date(1717243200000).toISOString()  时间戳转换
#   encodeURIComponent('a b/c')            URL 编码
#   'a,b'.split(',').map(Number)          简易 CSV 解析

# ② 依赖版本：看 lock 文件，不看 package.json
pnpm outdated                              # 哪些能升（基于 lock）
pnpm list --depth 1                        # 实际装的是哪些版本
npm ls express                             # 真实的传递依赖树
# 🔴 同一个 ^4.18.0 在两个项目里可能锁定 4.18.2 / 4.19.1 ⇒ 行为不同

# ③ 比较两个项目的真实依赖差异（比 package.json 可靠）
diff <(jq -S '.packages | keys' pnpm-lock.yaml)      <(jq -S '.packages | keys' ../other/pnpm-lock.yaml)
# 更完整的做法：把两个 lock 文件都规范化后 diff

# ④ Git 里查某个文件是谁改的
git log --oneline -- path/to/file
git blame -L 10,20 path/to/file            # 逐行溯源
git log --format='%an %ad %s' --date=short -- path/to/file

# ⑤ 检查仓库健康度（提交前自查）
git status --short                         # 有没有漏改的文件
git diff --stat                            # 改动规模
git log --oneline -1                       # 上一次提交信息是否清楚

# ⑥ API 调试：curl 比 Postman 快且可脚本化
curl -sS -X POST https://api.example.com/echo   -H 'Content-Type: application/json'   -d '{"a":1}' | jq .                      # 管道给 jq 美化
curl -sSI https://api.example.com/health | grep -iE 'status|cache|etag'

Practical Notes

Prompt reproducibility comes from fixed parameters, not wordingThe same prompt behaves very differently across temperatures and top_p values. To reproduce a result you must record the model version, sampling parameters and context length; saving only the text discards the experimental conditions.
Load tests must separate throughput and latency, and report error rateLooking only at QPS hides the tail: raising concurrency can multiply P99 latency while error rate climbs. Conclusions need concurrency, throughput, P95/P99 and error rate together, or the numbers explain nothing.
Screen and camera capture depend on codecs and permissionsIn-browser recording relies on codec support (H.264 is missing in some environments) and must request permission inside a user gesture, otherwise it is silently denied. Automated tests need explicit media permission flags on the browser.

Data Sources

Official documentation of each tool (no single external specification)

Codes, names and definitions above come from public specifications; we claim no originality over the specification data itself. The arrangement, Chinese annotations and practical notes on this page are written by us.

Three Frequent Developer Utilities

Utility	What It Does	Typical Use
AI Prompt Writing	Break a task into role, context, constraints and output format, then reuse as a template	Bulk-generating copy, code or SQL; keeping team output consistent
Benchmark & Load Test	Measure throughput, latency and resource use with repeatable scripts to compare implementations	Pre-selection load test, pre-launch capacity check, regression perf compare
In-browser Camera Recording	Call the camera/mic and record video in-page via getUserMedia + MediaRecorder	Demo capture, avatar collection, remote interview checks — all client-side

Practical Tips

Write role + goal first, constraints after

Open with one sentence that pins the model's identity and the deliverable (e.g. "You are a senior back-end dev; output a runnable Python function") — more stable than piling on adjectives. Put constraints later: input format, length, bans, examples.

Fix every variable but one when benchmarking

Concurrency, data size, hardware and dependency versions all pollute a comparison. Change exactly one factor per run and lock the rest so results stay comparable.

Request permission and provide a fallback before recording

getUserMedia needs HTTPS and user consent; mobile may not expose the rear camera. Always catch the error and tell the user to enable permission manually — never let the record button fail silently.

Frequently Asked Questions

What sections should a good prompt include?

The most stable shape has four parts: ① role (who you are) ② task and context ③ constraints (format, length, bans, terms) ④ examples and an output template. Short tasks can merge them, but role and output format almost always pay off — without them the model drifts.

Which numbers matter most in a benchmark report?

Prefer p95/p99 latency over the mean — the mean hides tail stalls. Then throughput (QPS/RPS) and resource use (CPU, memory, connections). If p99 jumps while the mean is flat, you have an intermittent block worth investigating more than a gentle mean regression.

Is in-browser camera recording safe? Does data leave the page?

getUserMedia only works over HTTPS (or localhost) and requires explicit user consent; the captured audio/video stream lives in the page's memory by default and is not uploaded anywhere automatically. Whether it is sent anywhere is entirely up to your own code — for sensitive cases, process it immediately and avoid writing to disk.

Are prompt, benchmark and recording tools often used together?

In demo/docs workflows they chain naturally: draft the narration with a prompt, record the walkthrough with the camera, and benchmark to confirm the demo environment does not stall under load. Treating them as one toolchain beats using each alone.