I like kotlin SpringBoot apps deployed to k8s. Go apps for custom k8s operators/controllers.

  • 24 Posts
  • 14 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle
  • 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.


  • Im a bit late to the show, but I personally feel like you are heading down the wrong path. Unless you are trying to completely host locally, but for some reason want your backups in the cloud, and not simply on separate local server, you are mixing your design for seemingly no reason. If you are hosting locally, you should back up to a separate local instance.

    If you indeed are cloud based, you SHOULD NOT be hosting a DB separately. Since you specified S3, you are using AWS, and you should rather use RDS managed mySQL and should use the snapshot feature built in. ref





  • 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)





  • 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).