Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)R
Posts
27
Comments
36
Joined
3 yr. ago

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

  • Removed

    White Box Testing

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

    The myth of 100% code coverage

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

  • In my opinion, it really depends on what type of place you would want to work. There are a lot of options out there, but (specifically for SRE) "cloud knowledge" is a must most places.

    I would consider someone with an SRE title more ops than dev, and wouldn't expect much in terms of writing code. I would more expect things like advanced knowledge of availablility, reliability, performance and observability on whatever cloud provider is being used. A Site Reliability Engineer is responsible for realiability of the deployed site, so it is dependent on the site/company on what the actual day to day would look like.

    This isn't to say you wouldn't have a place in DevOps with your current skills. However, it may be an easier route to start more on the dev side than the ops side as, in my experience, ops are harder to learn generically because every shop has different processes and operations.

    The dev side includes things like you mentioned (e.g. build/test execution/package/artifact publish/code release) and then mixes heavy into ops during deployment which then turns into SRE type stuff when the app is deployed to a real place. Often the dev side is done by people with Software Engineer type titles (potentially a DevOps team), and may even be done directly by the developers themselves.

    A lot of these processes include a developer needing to execute locally as well as repeatable execution by an automated system of some type (CI). Linux and bash knowledge is very useful for these types of things, as most of the time end deployment will be on a Linux distro, although development happens on OSx or Windows.

    The industry is already trying to change buzzwords, from DevOps to DevSecOps, so it is never bad to know security as well. Things like security vulnerability detection and remediation are very valuable and part of the "shift left" in terms of software delivery.

    You are welcome to read my comment history to see my feelings about python in DevOps, but they are not positive, and should just use bash, unless it is actually a python shop and other people know how to use python, or else it will most likely become a security vulnerability in and of itself.

  • 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

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

  • Auth

    Jump
  • AutheNtication vs. AuthoriZation, I believe

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

  • I rebase my dev branches on main to get rid of garbage commit messages due to me being lazy.

    Squash and merge PRs into main, no merge commits allowed.

    I think there are reasonable arguments for allowing rebase and merge to main, but it often doesn't apply for me.

    Merge commits in main will break a lot of out of the box GitOps tools.

  • This is an interesting option and probably pretty useful for python projects.

    Although I generally push back against use of python usage as a build tool (it is not a build tool), I know tons of people still use python scripts in their CI (as a build tool), which, I think only makes sense if you are a python shop. Why install python to build java, for example? (pro-tip - don't)

    Disclaimer: these opinions are mainly targeted toward closed source enterprise software.

    People love using all sorts of fancy stuff in their CI, and I am personally a CI purist. If it can be done in bash, do it in bash. See scripts-to-rule-them-all by GitHub, which I personally think is still too little, but at least sets a good foundation.

    CI purist examples:

    I am of the opinion that if one feels like they need credentials for their cloud provider in CI (besides cloud provider as artifact host), the project probably needs better unit testing rather than integration tests requiring all sorts of real creds to be injected. Does it take some extra time, sure, but arguing against push back for "better testing" is not an easy path to go, trust me. ("No!!! My couple integration tests with bunches of dependencies injected are easy and get a lot of code coverage!!" -- code coverage != good tests)

    I am also of the opinion that one shouldn't even be using things like 3rd party GitHub actions that one has no idea what they actually do, just that it works, and then auto bring in updates that one doesn't actually watch what is being updated. Sure it still works, but did it turn into malware, the project auto pulled in updates, and no one was watching? How does one know, if one isn't watching the upstream changes.

    CI/CD is primetime for supply chain attacks. It is not an if, but a when. Prepare for the inevitable.

  • not production ready vs. production ready

  • Kubernetes @programming.dev

    MYSQL on Kubernetes with PVC from a Block Storage Device

    www.portainer.io /blog/how-to-get-mysql-on-kubernetes-with-pvc-from-a-block-storage-device-working
  • Absolutely, which is why I never linked to Reddit. So I'm already loving and prefferring lemmy over Reddit 100%!

  • I won't parrot the reasons, I think other comments captured that.

    However, I would MUCH rather share links in professional circles to something called programming.dev that is specifically an instance about programming rather than "choose your random generic instance" that has porn, memes, shit posts, etc. and oh look, a programming community too.

  • Java @programming.dev

    Which Version of JDK Should I Use?

    whichjdk.com
  • commandline @programming.dev

    Vim Best Practices For IDE Users

    betterprogramming.pub /50-vim-mode-tips-for-ide-users-f7b525a794b3
  • DevOps @programming.dev

    Platform for monitoring the four key software delivery metrics of software delivery - DORA

    github.com /dora-team/fourkeys
  • Golang @programming.dev

    Write Go like a senior engineer

    levelup.gitconnected.com /write-go-like-a-senior-engineer-eee7f03a1883
  • Kubernetes @programming.dev

    A DeepDive Into Testing WireMock On K8s With Istio

    marinow.hashnode.dev /a-deepdive-into-testing-wiremock-on-k8s-with-istio