mshekow

A CLI and UI tool called "renovate-log-parser" to diagnose issues with Renovate Bot, using its debug log. It's supposed to accelerate this analysis, with several CLI commands (one meant for coding agents to save tokens when they read the log). If you want to try it, it's just one "npx renovate-log-parser" command away.

https://github.com/MShekow/renovate-log-parser

The numbers they provide are to be taken with a grain of salt. You cannot just say "node.js apps cache this much better than <some other technology> apps". This highly depends on the concrete code/package structure.

You might also learn quite a bit about BuildKit Caching from my blog post https://www.augmentedmind.de/2023/11/19/advanced-buildkit-ca...

I assume that wax uses Apple's ANE to do embeddings (so no third-party services like OpenAI are needed). Did you happen to compare search quality when using ANE embeddings vs. OpenAI's text-embedding-3-large (or another commonly used online embedding)?

Would wax also be usable as a simple variant of a hybrid search solution? (i.e., not in the context of "agent memory" where knowledge added earlier is worth less than knowledge added more recently)

oci.dag.dev is fantastic. You can also self-host it, because it's just a Golang CLI.

I compared it with various other registry browser tools, and it was clearly the best one. See here for more details: https://www.augmentedmind.de/2025/03/30/the-9-best-docker-re...

I'm German myself. To me this looks like a category of problem where you can no longer translate the word in the literal sense, because chances are low that the consumer understands the word ("Bremsschwelle" or whatever you end up picking).

Wouldn't it make sense to rather think of a completely different analogy? One that is really well-known by the target audience? From what I understand, you are building an app that inhibits people from doomscrolling. That is a well-established "German" word, too. Using that, people immediately understand what you mean, rather than trying to follow a broken analogy.

This guide looks really nice, targeting novice Git users.

I've also written a guide, targeting devs with basic Git experience. It is much shorter, maybe you or your team can benefit from it [1]

[1] https://www.augmentedmind.de/2024/04/07/ultimate-git-guide-f...

I found two ideas / techniques helpful in this context:

1) Conventional comments (https://conventionalcomments.org/) as an (agreed-upon) language to be used in PR comments

2) Ship / Show / Ask (https://martinfowler.com/articles/ship-show-ask.html), where "Show" and "Ship" are non-blocking PRs (or even directly committing to trunk, if you use trunk-based development), since not every(!) PR needs reviewing and/or should block the PR creator

Looks nice. I'm a Clockify fan myself. Your app and homepage also remind me a lot of https://timemator.com/ (which I ended up not using because it was unable to generate reports that show me the percentage(!) of time spent on different projects throughout the day).

I agree.

Also, in my experience, writing UI code is usually more(!) work than writing the functionality underneath, because

a) styling / layouting has to be learnt from scratch (e.g. because of a proprietary language, e.g. QML or QWidgets for Qt)

b) you have to take care of every frikkin' single user interaction (which becomes worse the more dynamic and custom your UI is), and building proper accessibility is also no walk in the park

The only option I know is to use network shares/disks, but you need to make sure that each share/disk is only used by one BuildKit process at a time.

I took a detailed look at Docker's caching mechanism (actually: BuildKit) in this article https://www.augmentedmind.de/2023/11/19/advanced-buildkit-ca...

There I also explain that IF you use a registry cache import/export, you should use the same registry to which you are also pushing your actual image, and use the "image-manifest=true" option (especially if you are targeting GHCR - on DockerHub "image-manifest=true" would not be necessary).

Sounds really interesting, and I'd also love a Firefox version :)

I also looked at this topic, see [1]. Some points are similar to the article posted by OP. My findings were:

- Docker Desktop and Docker engine (CE) behave differently, e.g. bind mounts, or file system ownerships.

- CPU/Platform differences (ARM vs. AMD64): many devs don't realize they use ARM on their mac, thus ARM images are used by default, and tools you run in it (or want to install) may be have differently, or may be missing entirely

- Incompatible Linux kernel APIs (when containerized binaries make syscalls not supported by the the host's kernel, for whatever reason)

- Using the same version tags, expecting the same result (--> insanity, as you know it :D)

- Different engines (e.g. Docker Desktop vs. colima) change the execution behavior (RUNNING containers)

- Different build engines (e.g. kaniko vs. BuildKit vs. buildah) change the BUILD behavior

For anyone who is interested: more details in [1].

[1] https://www.augmentedmind.de/2023/04/02/docker-portability-i...

It took me a while to understand what your tool is doing. It looks like an abstraction layer for concrete monitoring/alerting solutions.

What confuses me is:

- You introduce Keep like this "Think of Keep as Prometheus Alertmanager but for all observability tools", but then there is no Alertmanager provider. Is this planned?

- You mention that you support the 3 hyperscaler clouds (AWS, ...), yet I do not see any examples or code that backs this up

- You mention that Keep can be used to _test_ alerts. How? Examples? Otherwise make it clear that you _plan_ that Keep can do this at some point.

In general though it looks very interesting :).

containers.dev is a spec created and only implemented by Microsoft (in Visual Studio [Code]). Tool vendors (of IDEs) decided to go to war, instead of collaborating, it seems. XKCD's "standards" comic seems to apply [0] here.

As I've blogged about here [1], there are other specs such as Devfile.io or GitPod's proprietary gitpod.yml file.

[0] https://xkcd.com/927/

[1] https://www.augmentedmind.de/2022/10/30/container-based-deve...

To record "bookmarks" for interesting sections of podcast episodes (that I want to revisit some time later), I use my own (Android-only) app called "Stop It!" [0]. The mechanism that creates a bookmark is to pause and immediately unpause the playback (works with any headset). For each bookmark, the app records the audio player's Android package name, the artist / album / track name, the time code (in seconds) and other meta-data (if available). For selected audio players, the user can resume playback for bookmarks at a later time.

I have not worked on the app for a while, because it (still) works on my (old) Sony Android phone.

[0] https://github.com/MShekow/stop-it

I simply have such a kind of notebook placed in my shower (with a run-of-the-mill pencil) to jog down any ideas I have while under the shower. I have a variant that encourages ripping out pages.

Teaching Git to others (e.g. company-internal workshops). You learn so much from teaching, and also from questions others ask, helping you discover your unknown knows and unknown unknowns.

I found this blog article to be a good introduction to sigstore and the related projects (such as Fulcio): https://www.giantswarm.io/blog/securing-the-software-supply-...

How would Dagger compare to Toast? https://github.com/stepchowfun/toast