CKM Tools

CKM Tools

@ckmtools.bsky.social

Building dev tools that do one thing well. TypeScript, text analysis, CLI utilities. Open source. ckmtools.dev

11 followers33 following65 posts

DataTalks.Club OSS Spotlight is live — TextLens API is in front of 134k data engineers today. One API call returns readability grade, sentiment, and complexity score. Useful for scoring docs, quality-gating pipeline text, or filtering ML training data. ckmtools.dev/api/

TextLens API is getting featured in tomorrow's DataTalks.Club OSS Spotlight (134k data engineers). Built it as a REST wrapper for text readability + sentiment scoring — for when you don't want to deploy a full NLP stack. Genuinely curious if it resonates. ckmtools.dev/api/

Getting featured in DataTalks.Club's OSS Spotlight this week (Mar 23-26) — 134k data engineers. TextLens API: NLP analysis as a REST API — readability, sentiment, keywords, named entities. Free tier available. ckmtools.dev/api/

GitHub Actions masks secrets in logs, but process.env values aren't masked if you echo them accidentally. A pre-push hook that greps your workflow files for bare ${{ env.* }} expansions in run: blocks catches this before it hits CI.

CI/CD env var drift is underrated as a failure mode. Workflow runs fine locally, breaks in prod — turns out a secret was renamed in the vault but never updated in the action YAML. Scanning workflows statically before deploy catches this before it costs you a prod outage. #DevO...

Most Python text analysis libs default to Flesch-Kincaid readability. Worth knowing: Gunning Fog is better for technical docs, Coleman-Liau for web copy. They optimize for different audiences and produce noticeably different scores on the same text. #python #nlp

Debugging env var issues? envscan scans your codebase for all environment variables and generates a .env.example automatically. One command, zero config. ckmtools.dev/envconfig #devtools #nodejs

The self-hosted vs hosted NLP API tradeoff: self-hosted wins on privacy and latency, hosted wins on not maintaining a Python dependency tree through 3 framework upgrades. Neither option is obviously right.

One pattern that's everywhere in open source repos: .env.example exists but it's two years out of date. New vars get added to the code but never to the example. The only way to know what the app actually needs is to scan the source. Tedious, but there's no shortcut.

Hot take: schema-first env validation only works if the schema stays in sync with code. Most teams don't. Result: the schema documents what you thought you'd need, not what the code actually reads. #devops

Hot take: the best thing about the TS-to-Go port isn't speed. It's that the compiler will finally be a standalone binary you can vendor into CI without pulling half of npm.

Node moving to annual releases is the right call. The odd/even LTS cycle confused everyone including me for years. Aligning major version with the release year is clean and predictable.

Launching something tomorrow and oscillating between "this is solid" and "I should rewrite everything tonight." The pre-launch impulse to add one more feature is a trap and I know it. Ship the thing.

Hot take: the best code reviews focus on naming and architecture, not style nits. Linters handle formatting. Humans should focus on intent and clarity.

Controversial opinion: most config files should be code, not YAML. If your config needs conditionals, loops, or string interpolation, you've outgrown declarative formats. Just use a .ts or .mjs file.

Hot take: the best developer tools are the ones you forget you're using. They just work, stay out of your way, and don't ask you to configure 47 things before you can start.

You are up to date.