A Java geek

Recently, while working on a workshop titled Testing Your Pull Request on Kubernetes with GKE, and GitHub Actions, I faced twice the same issue: service A needs service B, but service A starts faster than service B, and the system fails. In this post, I want to describe the context of these issues and how I solved them both with the same tool. Waiting in Kubernetes It might sound strange to wait in Kubernetes. The self-healing nature of the Kubernetes platform is one of its biggest benefits.

While working on my demo on WebAssembly and Kubernetes, I wanted to create three different binaries based on the same code: Native: compile the Rust code to regular native code as a baselineEmbed: compile to WebAssembly and use the WasmEdge runtime image as the base Docker imageRuntime: compile to WebAssembly, use a base scratch image as my base image, and set the runtime when running the code The code itself is an HTTP server that offers a single endpoint. For the sake of the demo, I wanted it

I have presented my OpenTelemetry demo many times, and I still do. Each time, the audience is different. To make no two presentations the same, I always ask attendees what stack they are more interested in. I also regularly add new features for the same reason. I was a victim of the IT crisis last summer, and my company fired me, so I no longer work on Apache APISIX. They say that the Chinese ideogram for crisis contains the ideogram for opportunity. I used this opportunity to join LoftLabs. Lo

I’ve been a big fan of Mutation Testing since I discovered PIT. As I dive deeper into Rust, I wanted to check the state of mutation testing in Rust. Starting with cargo-mutants I found two crates for mutation testing in Rust: cargo-mutantsand mutagen mutagen hasn’t been maintained for three years, while cargo-mutants is still under active development. I’ve ported the sample code from my previous Java code to Rust: struct LowPassPredicate { threshold: i32, } impl

Garbage collection in Java takes care of memory management, but it does not clean up non-memory resources like sockets or file handles. Resource leaks may occur without proper management, leading to performance degradation or crashes. Java’s Cleaner API, introduced in Java 9, provides a modern and efficient mechanism for resource cleanup when objects are no longer reachable. It addresses the shortcomings of the deprecated finalize() method, offering a predictable and efficient way to manage

The ideal size of your Kubernetes clusters is a day 0 question and demands a definite answer. You find one giant cluster on one end of the spectrum and many small-sized ones on the other, with every combination in between. This decision will impact your organization for years to come. Worse, if you decide to change your topology, you’re in for a time-wasting and expensive ride. I want to list each approach’s pros and cons in this post. Then, I’ll settle the discussion once a

Recently, my good friend Richard Fichtner advised using the mvn dependency:analyze command to get rid of declared but unused dependencies: There is another use case for mvn dependency:analyze It can show you the dependencies you use in your code but have not declared in your pom.xml. This works because you have a transitive dependency on your classpath. Either don't use the dependency or declare it.[image or embed]— Richard Fichtner 💻☕ (@richard.fichtner.dev) December 10, 2024 at 2:

Like a couple of innovative technologies, different people have different viewpoints on where WebAssembly fits the technology landscape. WebAssembly (also called Wasm) is certainly the subject of much hype right now. But what is it? Is it the JavaScript Killer? Is it a new programming language for the web? Is it (as we like to say) the next wave of cloud compute? We’ve heard it called many things: a better eBPF, the alternative to RISC V, a competitor to Java (or Flash), a performance booster

This week’s post is the third and final in my series about running tests on Kubernetes for each pull request. In the first post, I described the app and how to test locally using Testcontainers and in a GitHub workflow. The second post focused on setting up the target environment and running end-to-end tests on Kubernetes. I concluded the latter by mentioning a significant quandary. Creating a dedicated cluster for each workflow significantly impacts the time it takes to run. On GKE, it t

I’m continuing my series on running the test suite for each Pull Request on Kubernetes. In the previous post, I laid the groundwork for our learning journey: I developed a basic JVM-based CRUD app, tested it locally using Testcontainers, and tested it in a GitHub workflow with a GitHub service container. This week, I will raise the ante to run the end-to-end test in the target Kubernetes environment. For this, I’ve identified gaps that I’ll implement in this blog post: Create