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)
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.
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).
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
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).
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].
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.
containers.dev is a spec created and only implemented by Microsoft (in Visual Studio [Code] and GitHub Codespaces). 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.
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.
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.
3) The Windows installation tutorial links to another article (https://www.redhat.com/sysadmin/podman-windows-wsl2) that is, by today's measurements, _very_ old, because... ? I cannot imagine that things have not changed since then, I refuse to believe it :D
From what I understand, Podman will become an _actually_ easy to use and viable solution to Docker for Desktop once Podman 4.1 has been released, and we have host volume mount support, which is a must-have feature for development.