docker

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-08-28

Final complete day: 2026-08-28. Attention was 0.9% — this entity appeared in 23 of 2,594 analyzed posts/comments in the seven days ending that day (40 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-08-28 22:50 UTCPost

   lerna vs nx vs release-please vs dispat: deterministic, idempotent releases that work past npm - My monorepo has six binaries, Go modules, four Docker images and a Docusaurus site that depend on each other. Publishing this writes to the repository, a container registry, cloud and GitHub. These are four independent services with no shared transaction. Published versions are immutable, so there is no rollback. This is a distributed transaction over non-transactional resources, which is exactly the situation sagas were invented for in 1987. You recover by finishing the job, never by unwinding it. **The two properties that matter** Determinism means a fixed repo state and config always produce the same plan on any machine. The plan is a pure function of git history, the dependency graph and config. Nothing reads the clock, commit dates, tag creation order or map iteration order. CI and my laptop agree byte for byte. Idempotency means running twice with nothing new committed gives the same plan, and running after a fully successful release gives an empty one. An accidental double run is a no-op instead of a second release. Every tool here gives you something like this on npm. The difference is where it comes from. **Their idempotency is npm's, not theirs** lerna has a documented recovery path using `lerna publish from-package`, which compares each package's local version against what is published and ships the difference. nx and release-please lean on the same shape. A version step writes tags, a later step publishes, and if that step dies you re-run it. This genuinely works, and I want to be fair about why. npm makes it work. Versions are immutable and a duplicate publish is a hard error, which I saw in my own runs as a 409 Conflict. The registry is the source of truth you reconcile against. Now take that away. There is no `from-package` for a Docker tag, a GitHub release, a Maven deployment or a `terraform apply`. The moment a release spans targets you cannot diff against, the property stops being inherited. It has to come from somewhere else. In dispat it comes from the model. The tag store is the log. A tag is written after a package publishes, so a tag means that leg committed. The plan is a pure function, so re-running recomputes the exact same transaction and executes only the legs with no record. Nothing is queried because nothing needs to be. Determinism and idempotency hold for a Docker image, a GitHub release or an applied Terraform plan exactly as they do for npm, because none of it depends on the target being able to answer questions. **They are all one algorithm with the constants frozen** This surprised me when I wrote the model down. lerna, nx release and release-please compute versions from the same three inputs: conventional commits, per-package tags and a dependency graph. In my model each commit carries a propagated bump and a depth. Freeze that depth at infinity and the bump at patch for every commit, and you get their behaviour exactly. Every dependent of anything released takes a patch transitively. Their `fix: x` is my `fix(core)^^: x`, and their lockstep modes are the degenerate case where the workspace shares one version. The experiment showed it. I used the same six-package graph and one `feat(core)` commit. lerna bumped core and all five dependents, including two that only depend on `ui` and never saw the change. dispat with an explicit `^` bumped core and its three direct consumers. Same math, different constants. **The failure case, executed** I set up a sandbox, a local registry and a proxy failing exactly one upload. lerna writes tags and a commit before `lerna publish` uploads. After the failure there was a `cli@1.0.1` tag for a version the registry did not have. `from-package` then refused to run because the failed publish had left the tree dirty. It threw EUNCOMMIT until I ran `git checkout` by hand. After that it recovered npm correctly. dispat wrote no tag for the failed package. Re-running shipped exactly what was owed at the same versions. A third run planned nothing. |tool|lerna|nx release|release-please|dispat| |:-|:-|:-|:-|:-| |Log record|tag before publish|tag before publish|tag on PR merge, publish later in CI|tag after publish| |Idempotency comes from|npm registry diff|npm registry diff|CI job plus registry|the model, any target| |Recovery|`from-package`|re-run steps|re-run the CI job|run the same command again| |Blast radius|all dependents, patch|all dependents, patch|all dependents, patch|explicit: `^`, `^^`, `+N`| |Task caching|nx computation cache|nx computation cache|n/a|none needed, unchanged packages never run| |Ecosystems|npm|npm-centric|npm and others via plugins|35 manifest formats, or any shell command| (I executed lerna and dispat. The nx and release-please rows come from their docs. release-please is GitHub API coupled with no hermetic mode, so I could not run it in a sandbox and will not pretend I did.) **It is also the task runner** `dispat run tests --since HEAD~1 --consumers` runs a script in exactly the changed packages and their consumers in dependency order. `dispat if 'CI!=true' --then '...' --else '...'` and `dispat if --changed` keep the conditionals in config instead of a wall of CI bash. `dispat replacer` fixes coordinates no manifest writer reaches, like a Gradle line or a README install snippet. There is no task cache, deliberately. A package that did not change is not in the plan, so its scripts never start. There is nothing to hash, invalidate or warm, and no cache key to get subtly wrong. Whatever your stages already cache keeps working inside them, BuildKit layers or a Gradle cache included, and none of it can affect versions, order or tags. **Proved, not asserted** I wrote eight guarantees over the formal model. Determinism and idempotency are among them, plus no orphaned consumers, exactly-once delivery, retries landing on the same versions and repeated runs converging to an empty plan. I ran randomised differential testing of the binary against that model. 1,500 of 1,500 instances agree exactly. There are also 240 conformance vectors, 1,831 tests and 32 fuzz targets. It releases itself. That is a 12-package workspace across 3 ecosystems with 11 published in one transaction. Because a leg need not be a registry upload, the same machinery ships my cloud footprint as stateless Terraform. I put the plan in build and the apply in publish, with no remote backend, and the tag history acts as the list of applied states. Docs and demo clips: Repo (MIT):

2. 2026-08-28 13:22 UTCComment

   Necessity is the mother of all invention! I got tired of paying the high cost for Vercel which I used as an opportunity to learn how to use Docker properly, and I've never looked back.

3. 2026-08-28 04:41 UTCComment

   I would also suggest making your apps docker containers so its easy to deploy anywhere. If purpose is learning rhe stacks, then use these and host them on a vps. Hosted solutions like firebase and all can be picked once you have a good understanding of this

4. 2026-08-27 12:37 UTCComment

   When MAMP dies out of nowhere it is usually the Apache or MySQL port being taken by something that updated overnight, so check the error log and whether the ports are already bound. If you want it to stop happening, a small docker compose file for php and mysql is a couple of hours of setup that never breaks on an OS update.

5. 2026-08-27 10:53 UTCComment

   God’s way of saying use Docker.