jsonnet[1] and kapitan[2] are the tools I currently use. Their learning curve is not optimal (and I tried to contribute to smoothen it with a jsonnet course[3] and a 'get started wit kapitan' blog post[4]), but once used to it it's hard to do without, and their combination makes them even more useful (esp. if you deploy K8s).
In Ruud's case, Jsonnet might have been worth looking at as Hashicorp tools can be configured with json in addition to HCL. But that would have been less fun I guess ;-)
I hope for Ruud it finds its niche, there's quite some competition in this field!
> I never properly evaluated Jsonnet, but probably I should. Superficially it looks like one of the more mature formats, and in many ways it looks similar to RCL. Its has a page comparing itself against other configuration languages.
Kapitan sounds interesting. It definitely looks difficult to figure out. Even your blog post only gives me a hint, leaving me with lots of questions. I am going to o dig deeper.
Kapitan founder here! Please reach out on the kapitan channel of the kubernetes slack, or connect with me on LinkedIn https://www.linkedin.com/in/alledm
I have been working on a couple of video tutorials that could be helpful to get started
Genuine question: I'm curious to know why you deploy with docker-compose and not Docker swarm (eg like described at https://dockerswarm.rocks/ ). I'm deploying the same kind of apps, and ended up with Swarm which seems to fit perfectly. I also found Kubernetes much too complex for my use case. Curious to know why we ended up with different outcomes.
Btw, I also use Compose, but for local runs (of other apps).
Docker Swarm uses compose files too.
Swarm is still used and maintained, though I agree it is much smaller than k8s.
But that's not a reason to dismiss it I think. I went for it because it's so easy to use that if I need to migrate off of it, I would not loose a lot of investment in it anyway.
I'm sure swarm would work for what I need and rationally its probably worth using, but I only trust docker as far as I could throw them and if I needed to really deploy I would probably just suck it up and figure out k8s.
I've been very happy with until now, though i must admit i'm using one node swarms. But i'd rather use that (1) than sticking together a custom solution using docker compose as i see it mentioned sometimes.
I'm using Playwright [1] (dotnet version) to test my web app, and I mainly use XPath to identify elements on a page. I found it to be to the best choice in my use case, mainly because it is composable. I can define an XPAth to a table `tableXPath` and then reuse it to identify a cell in the table like eg $"""{tableXPath}//td[text()="my value"]""", and I can further reuse that to identify a sibling cell which might trigger an action.
NvChad[1]is the first vim/neovim config that worked for me for coding. What I also like in NvChad is that all my custom configs can be placed under a `custom` directory, leaving the provided config as is and easing upgrades of NvChad itself. This doesn't seem to be the case with LazyVim.
I think it shows in the community management that F# originated in a closed-source environment. For example, it is required to be a member of the F# Software Foundation to get access to F# Slack. Putting such a roadblock early in the discovery of the community is a sure way to limit your growth.
In Ruud's case, Jsonnet might have been worth looking at as Hashicorp tools can be configured with json in addition to HCL. But that would have been less fun I guess ;-)
I hope for Ruud it finds its niche, there's quite some competition in this field!
1: https://jsonnet.org/
2: https://kapitan.dev/
3: referal link: https://www.udemy.com/course/jsonnet-from-scratch/?referralC...
4: https://www.yvesdennels.com/posts/starting-with-kapitan/