Yes, written communication is so tricky, esp RE sensitive topics like this. As a non-native speaker, I kind of knew I was going to mess it up, but I guess I just couldn't help my OCD π
donate to you instance.
That's a good sign of support and I've already done that π Honestly the quality of the software and the friendliness of the community made it a no-brainer for me only a few days after logging in for the first time.
That said, I think there's more I can do than my humble donation - I've got plenty of, hopefully, relevant experience under my belt and am eager to put it to good use for Lemmy.
Servers are expensive and improving reliability will increase hosting cost.
Definitely π―
What I was trying to get at in my post was not rather improve the hardware or ask lemmy.ml folks to sweat more for free. By the gods, no! Rather I was suggesting that maybe w/ a couple of, hopefully, easy and not time consuming moves we could up our level at lemmy.ml. Though I realised what I was talking about, wasn't among the main concerns of the community. Which is totally reasonable.
I had no idea about that π€¦ββοΈ Bookmarked π
I'd find it a useful thing to have too π Please see https://lemmy.ml/post/4196612 for a similar post (by me.)
Not a show-stopper in any way though πͺ
I've been using sdkman for about a decade now and am totally pleased w/ it. It does a very good job of managing JDK versions for you and much more, eg SBT, Gradle, Scala, Groovy, Leiningen, SpringBoot, ...
Now, technically you could use sdkman in your CI/CD pipeline too but I'd find it a strong smell. I've always used dedicated images pre-configured for a particular JDK version in the pipeline.
It is: https://opensource.org/license/mit/
It's most probably a bug in the addon. Best to report it on the repo's issue tracker: https://github.com/galdor/github-license-observer/issues
Oops! My mistake π€¦ Updated the post.
I work primarily on the JVM & the projects (personal/corporate) I work w/ can be summarised as below:
- Building & running the repo is done on the host using an SCM (software configuration management tool) such as Gradle or SBT.
- The external dependencies of the repo, such as Redis, are managed via a
docker-compose.yml
. - The README contains a short series of commands to do different tasks RE (1)
However one approach that I've always been fond of (& apply/advocate wherever I can) is to replace (3) w/ a Makefile
containing a bunch of standard targets shared across all repos, eg test
, integration-test
. Then Makefiles are thinly customised to fit the repo's particular repo.
This has proven to be very helpful wrt congnitive load (and also CI/CD pipelines): ALL projects, regardless of the toolchain, use the same set of commands, namely
make test
make integration-test
make compose-up
make run
In short (quoting myself here):
Don't repeat yourself. Make Make make things happen for you!
I forgot to mention that the "artwork" is by yours truly. And yes, a 1st grader would probably have done a better job π
The first few paragraphs were a good read where the author makes a good point.
Sadly, it somehow turns into a BluSky promotion afterwards.
Good read, nonetheless.
Good point! I just replaced my LI profile photo w/ an abstract image π»
Created an issue on the repo: https://github.com/galdor/github-license-observer/issues/5