I prefer Sealed Secrets over sops since it has the namespace scoping element and can also be stored in repo (once encrypted). I also generally prefer having a controller deployed rather than forcing devs to learn kustomize (which we don't widely use yet) so I guess less of a support burden for me.

I think JetBrains has fully bought into Gradle. I think Maven support has been less and less over time, which shouldn't be a surprise. Gradle supports native Kotlin build scripts (i.e. build.gradle.kts), as well as putting a lot of work into ensuring their tools fit well within the Gradle ecosystem (exhibit A: https://github.com/JetBrains/intellij-platform-plugin-template). I think it only natural for the creator/owner/maintainer of Kotlin to go full in on the build system that supports the language!

controversial take: who still uses maven? who would prefer xml files over build scripts? (ok... fine, big timers like RedHat definitely do, or at least, have never taken/don't want to take the time to upgrade lol)

I prefer a similar workflow.

I am a major advocate of keeping CI as simple as possible, and letting build tools do the job they were built to do. Basic builds and unit/component testing. No need for overcomplicating things for the sake of "doing it all in one place".

CD is where things get dirty, and it really depends on how/what/where you are deploying.

Generally speaking, if integration testing with external systems is necessary, I like to have contract testing with these systems done during CI, then integration/e2e in an environment that mimics production (bonus points if ephemeral).

You may get more traction asking in the communities that exist for those tools: IntelliJ and Docker

8GB for two separate IntelliJ projects sounds low. You could try importing both into one instance as separate "modules" so that there is only one IntelliJ instance/window.

Depending on how you are running the VM, the host may be choking it through the host OS and leading to OOM. Especially with a tool like docker.

Edit: I see you commented usage of windows, you may need to look into wslconfig

Hi friend, sounds like you should join us over in devops@programming.dev :)

It is important, and effective, to properly track and show to teams what effect their code changes have to the system and what "their team's process" looks like to an outsider with meaningful data.

More here https://programming.dev/post/80365

Ahh, that would make more sense, thank you - corrected

Depending on where you want your app to run, QT framework/creator has pretty powerful C++ GUI capabilities. The biggest benefit, I thought, is a lot of open source projects use it (e.g. Bitcoin and forks) meaning there are a lot of real examples out there rather than only docs.

The other option, which is more aligned with separate frontend/backend and WebApps, is simply have a basic server of some type wrapping the dll functionality you want to use as endpoints and communicate over ReST API.

After looking at my subscribed, rather the community list as a whole, I'm torn between 1/2

I can help mod IntelliJ

I write a lot of bash scripts that end up running in automation in some fashion.

#!/usr/bin/env bash

set -euxo pipefail

Is pretty standard for me.

-e exit on error

-o pipefail exit on pipeline fail

-u error on unset variables

-x trace

How I have never heard of yq, I'm unsure, but thank you as I'm sure it will make life easier