Carpeweekem looks like a really cool idea!
I suppose you exclusively use it for goal tracking and not for ongoing/open To Dos, right? At least if you don't carry over stuff from last week?
You could take a look at Obsidian [1], or similar knowledge management tools.
There is certainly a lot of movement in the plugin ecosystem right now, for example the obsidian-canvas-llm-extender [2], which (likely) does what you're asking for.
I always found Obsidian and whatever other tools a huge time investment by itself with more effort to use them than actually getting the managed knowledge.
Same for Anki, Notion, Zettelkatsen etc. Even ignoring the setup cost, it costs as much effort to insert in something as it does to retrieve it. The value prop tends to be low for individuals.
A technique I've found that works for learning languagea in Anki is to generate or download massive deck, suspend all of it and then whenever I encounter an unfamiliar word in the wild I unsuspend it and set it up for review. Takes like 5 seconds.
As much as I love Anki there is enormous friction in creating the cards, especially as a beginner. And you very easily get overfitting when you keep seeing the same question.
From a users point of view: If I'm interested in a project, I usually try to run it locally for a test drive. If you make me jump through many complex hoops just to get the equivalent of a "Hello World" running, that sucks big time.
From a customers point of view: Ideally you want both, local and cluster deployment options. Personally I prefer a compose file and a Helm chart.
In this specific case I'd argue that if you're interested in running an OSS project management product, you're likely a small/medium business that doesn't want to shell out for Atlassian - so it's also likely you don't have k8s cluster infrastructure, or people that would know how to operate one.
Take a look at all the configs and moving parts checked in this very repo that are needed to run a self-hosted instance.
Yes, it is somewhat nicely abstracted away, but that doesn't change the fact that in the kube directory alone [1] there are 10 subfolders with even more config files.
> Yes, it is somewhat nicely abstracted away, but that doesn't change the fact that in the kube directory alone [1] there are 10 subfolders with even more config files.
mongodb supporting service
minio supporting service
elastic supporting service
account their service
workspace their service
front their service
collaborator their service
transactor their service
rekoni their service
I still would opt for something simpler than that and developing all of the above services would keep multiple teams busy, but the Compose format is actually nice when you want to easily understand what you're looking at.
As someone that develops native Kubernetes platforms: Providing the raw resources / manifests is almost the worst way of providing a user install.
That works great as long as you never have a breaking change in your manifests or any kind of more complex upgrade.
Which brings me back to the initial question: Is this complexity and the external dependencies really needed?
For a decently decomposed, highly scalable microservice architecture, maybe.
For an Open Source (likely) single tenant management platform? Unlikely.
It highlights the problem of clashing requirements of different target user groups.
We can also take a look at the linux kernel that powers the docker instances and faint in terror.
These “moving parts” are implementation details which (iiuc) require no maintenance apart from backing up via some obvious solutions. Didn’t they make docker to stop worrying about exactly this?
And you don’t need multiple roles, specialists or competences for that, it’s a one-time task for a single sysop who can google and read man. These management-spoiled ideas will hire one guy for every explicitly named thing. Tell them you’re using echo and printf and they rush to search for an output-ops team.
These moving parts require active understanding and maintenance, as they will change on each and every upgrade, which also requires manual upgrade steps and potential debugging on breaking changes.
OCI images let you worry less about dependencies, but what they don't eliminate is debugging and/or upgrading k8s configuration manifests (which we are looking at here).
> We can also take a look at the linux kernel that powers the docker instances and faint in terror.
Sure, and computers are rocks powered by lightning - very, very frighting. That doesn't invalidate criticism about the usability and design of this very product my friend.
These moving parts require active understanding and maintenance, as they will change on each and every upgrade, which also requires manual upgrade steps and potential debugging on breaking changes
Maybe they won’t change or migrations will be backwards-compatible. We don’t know that in general. Pretty sure all the software installed on my PC uses numerous databases. But somehow I never upgraded them manually. I find the root position overdefensive at best.
If it were a specific criticism, fine. But it uses lots of assumptions as far as I can tell, cause it references no mds, configs, migrations, etc. It only projects a general idea about issues someone had at their org in some situation. This whole “moving parts” idiom is management speak. You either see a specific problem with a specific setup, or have to look inside to see it. Everything else is fortune telling.
Very fun article to read!
There's one catch: Go styleguides strongly recommend short variable names.
They do have a whole chapter about single/double letter vars [1] which boils down to:
They have their place, as receiver variables and in any place where the short name would be too repetitive.
Kind of nice visuals, although I still prefer functionality and speed over visual sparkles.
For entertainment and a no-fluff service, I still recommend https://wtfismyip.com/, which offers the data in any output format you could ever need
There is an EU Court ruling that found that EULA/TOS are not applicable or enforceable in Europe, so that's kind of a non-issue.
Also, this doesn't really change the outcome if a publisher would be forced to guarantee usability of their product after they shut down servers, does it?
You'd be surprised about the amount of people wanting this kind of smartphone.
The success of Framework, who are doing something similar in the Laptop world, could be a robust indicator for the demand.
Especially the replaceable battery is something we really should get back to IMHO.
