A Java geek

It’s hard nowadays to ignore Kubernetes. It has become the ubiquitous platform of choice to deploy containerized applications. In a few years, Kubernetes has entrenched itself deeply in the DevOps landscape under the tutelage of the Cloud Native Computing Foundation. One could speculate about the reasons. IMHO, one very compelling argument is that it allows users to be independent of the API of a single cloud provider. If you’ve been living under the monopoly of Microsoft on the deskt

If you’ve been working in Java since 'quite some time', you probably are experienced in using Map objects. One very frequent use-case is to check if a Map contains a value: Get the valueIf the value is null, put an initial value.If isn’t, transform the get value and put the new value into the map under the same key Map<String, Integer> map = new HashMap<>(); // ... Integer value = map.get(key); if (value == null) { map.put(key, 1); } else { map.put(key, ++valu

There are a lot of different ways to configure containers running on Kubernetes: Environment variablesConfig mapsVolumes shared across multiple podsArguments passed to scheduled podsetc. Those alternatives fit a specific context, with specific requirements. For example, none of them allow you to clone a Git repository before the container starts. It would be possible to design that feature into the image itself. Yet, that would introduce coupling, and defeat the Single Responsibility principl

This is the 3rd post in the Stream Processing focus series. Last week, we had a look at how stream processing could help us compute mathematical approximations using Hazelcast Jet. We described the Pipeline API, and mentioned that it drew from a source and drained to a sink. This week, I’d like to detail those concepts, what out-of-the-box sinks and sources are available in Jet, and how to create your own should the need be.

This is the 2nd post in the Stream Processing focus series. Last week, we had a look at what is stream processing. In this post, I’d like to address one possible use-case for stream processing: the computation of mathematical approximations.

This is the 1st post in the Stream Processing focus series. If software is eating the world, data is the new oil. Those who are able to best manage the huge mass of data will emerge out on top. The state-of-the-art way to refine this oil is stream processing. In this post, I’d like to describe what is stream processing, and why it’s necessary in this day and age.

Minification (also minimisation or minimization) is the process of removing all unnecessary characters from the source codes of interpreted programming languages or markup languages without changing their functionality. These unnecessary characters usually include white space characters, new line characters, comments, and sometimes block delimiters, which are used to add readability to the code but are not required for it to execute. Minification reduces the size of the source code, making its tr

Last week, I wrote about the creative use one can make of Filters by grading assignments of students. About, there’s another recurring issue that warrants a blog post: servlet mappings. While servlet mappings seem easy on the surface, they sometimes can be the cause of huge headaches. The issue In the assignment mentioned above, students have to create a mock e-commerce shop application. The home page shows a title, an introduction phrase, as well as a catchy image. The issue is that th

I’ve just finished grading the assignments of my students for the semester. I change the assignment every now and then. The current one is a very simplified e-commerce shop. The main feature revolves around a couple of screens, and cart management: The product detail page is mainly composed of the product detail component. One can add one such product to the cart by clicking the Cart button The products list page aggregates a couple of product detail components. One can add one for each

Most tutorials about Git history rewriting state that history should never ever be rewritten. Like all principles, it depends mostly on the exact context. The principle should probably be updated like this: Public Git history should not be rewritten The reason is that once the Git history has been pushed, it has been made public: other developers might have started working on top of it. Then, and only then, is rewriting the history an issue. It also means that sometimes, there are reasons