I like kotlin SpringBoot apps deployed to k8s. Go apps for custom k8s operators/controllers.
I have been using “gaming” keyboards for coding for ~10 years now. The only thing to be wary of imo, is keebs that have “extra customizable keys” on them and break conformity from a standard layout. Depends on the device, but Logitech will call them “G keys”, for example, and often stick them on the far left of the board, left of tab/caps/L shift. Makes life a lot more difficult if not gaming.
Outside of that, I think calling something a “gaming” keyboard is more of a marketing tactic to up the price. It’s hard to not recommend mechanical, but that sounds out of budget and often hard to do wireless/bluetooth, but personally I think mech is the top priority.
What I have seen a lot of peers do is wait to see whatever keyboard the get in office, then buy the same one for home for consistency, rather than dragging a personal one back and forth. Often companies will offer basic boards like logitech K270, K350, or K650. Not amazing, not terrible, and most likely fit in your described criteria.
Laughs in object
I am not as familiar with Cloud Native DevOps Newsletter but I do enjoy the podcast
December 8th, 2009 - Motorola Droid successfully rooted … [granting] root access on the phone using a terminal emulator. This is how I learned bash which inevitably pushed me into pursuing proper Computer Science.
I believe in GitHub branch protection rules, you can set required review by a code owner, as well as set an amount of reviews required.
You are also able to structure codeowner files and assign codeowners to certain paths within the repo that they “own”, rather than all or nothing.
You are able to set bypass rules for certain individuals, and as repo admin there is a little checkbox on PRs that will appear by default to allow you to ignore the requirements, although it is generally not recommended, but I won’t harp on the reasons others have already pointed out.
disclaimer: I mainly work on a GHES instance, which may be function slightly different than public GH
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)
December 8th, 2009 - Motorola Droid successfully rooted … [granting] root access on the phone using a terminal emulator. This is how I learned bash which inevitably pushed me into pursuing proper Computer Science.
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).
Just make sure to test the regex instead of blindly slapping it in assuming it works 🙂
It covers each and every line of the source code, each and every conditional statement in the program and every loop otherwise known as iteration in the program.
I think it is important to note 100% code coverage (“covers each and every line”) does not mean the tests are good tests.
Yes, I write SpringBoot microservices and IntelliJ plugins using Kotlin. Any new code is Kotlin, but there is still a ton of Java, which I don’t consider “legacy”, since it works, and if I can sanely add Kotlin when necessary, I don’t see the need for “full rewrite”.
You may get more traction by asking the Kotlin community
I did not know this, thank you for sharing. I am going to leave the comment because it has generated some good discourse (and hopefully maybe more) and in my reality, I don’t think I would even notice if this instance chooses defederation.
I look towards the experts to try and form my opinion here, as I am not one.
Our stance: We have been advocating for interoperability between platforms for years. The biggest hurdle to users switching platforms when those platforms become exploitative is the lock-in of the social graph, the fact that switching platforms means abandoning everyone you know and who knows you. The fact that large platforms are adopting ActivityPub is not only validation of the movement towards decentralized social media, but a path forward for people locked into these platforms to switch to better providers. Which in turn, puts pressure on such platforms to provide better, less exploitative services. This is a clear victory for our cause, hopefully one of many to come.
https://blog.joinmastodon.org/2023/07/what-to-know-about-threads/
I see that full blog as a “threads is good for the fediverse”. I only look at and interact with local on this instance, but am generically against jumping to defederation because “no like”.
The most simple way of explaining the cloud computing is storing, accessing, and processing data over the internet instead of using a traditional client server architecture.
Just because your compute is “in the cloud” doesn’t mean it isn’t a server, and it definitely can still be client/server architecture
Cloud provider hosted server accessed by client = client/server architecture
Interpreted language != Compiled language
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
Thanks for sharing! I will need to look deeper into build kit. Containers aren’t my main artifacts, unfortunately, so I am still building them the ways of old, sounds like.
Be really careful when building images that require secrets for build configuration. Secrets can be passed in as build args, but you MUST UNSET THEM IN THE DOCKERFILE and then repass them in as environment variables at runtime (or else you are leaking your secrets with your image).
Also, image != container. Image is the thing you publish to a registry (e.g. dockerhub). Container is an instance of an image.
Although I despise their software, I do enjoy their engineering blogs, thanks for sharing.
I find it very difficult to recommend generative ai as a learning tool (specifically for juniors) as it often spits out terrible code (or even straight up not working) which could be mistaken as “good” code. I think the more experienced a dev is, the better it is to use more like a pair programmer.
The problem is it cannot go back and correct/improve already generated output unless prompted to. It is getting better and better, but it is still an overly glorified template generator, for the most part, that often includes import statements from packages that don’t exist, one off functions that could have been inline (cannot go back and correct itself), and numerous garbage variables that are referenced only once and take up heap space for no seemingly no good reason.
Mainly speaking on GPT4, CoPilot is better, both have licensing concerns (of where did it get this code from) if you are creating something real and not for fun.