Posted on

Faster Maven Builds

Builds require a few properties, chief among them reproducibility. I would consider speed to be low on the order of priorities. However, it's also one of the most limiting factors to your release cycle: if your build takes T, you cannot release faster than each T. Hence, you'll probably want to speed up your builds after you've reached a certain maturity level to enable more frequent releases.

I want to detail some techniques you can leverage to make your Maven builds faster in this post. The following post will focus on how to do the same inside of Docker.

Posted on

Annotation-Free Spring

Some, if not most, of our judgments regarding technology stacks come either from third-party opinions or previous experiences. Yet, we seem to be adamant about them. For a long time (and sometimes even now), I've seen posts that detailed how Spring is bad because it uses XML for its configuration. Unfortunately, they blissfully ignore the fact that annotation-based configuration has been available for ages. Probably because of the same reason I recently read that Spring is bad... because of annotations. If you belong to this crowd, I've news for you: you can get rid of most annotations, and even more so if you're using Kotlin. In this post, I'd like to show you how to remove annotations for different features that Spring provides.

Annotation-Free Beans

The first place where we tend to set annotations is to register beans. Let's see how to move away from them. It involves several steps. We shall start from the following code:

Posted on

Updating Data Files, Commits vs. Pull Requests

For once, I'm wondering a bit if this post can be helpful to somebody else. I believe my context is pretty specific. Anyway, just in case it might be the case, here it is.

My Jet Train project makes use of GTFS. GTFS stands for General Transit Feed Specification. It models public transportation schedules and their associated geographic information.

Posted on

Rust’s Vector

I'll be honest: I initially wanted to describe all collections available in Rust as well as their related concepts. Then, I started to dig a bit into it, and I decided it would have been (much) too long. For that reason, I'll restrict the scope to the Vec type.

  1. My first cup of Rust
  2. My second cup of Rust
  3. The Rustlings exercises - part 1
  4. The Rustlings exercises - part 2
  5. Rust on the front-end
  6. A Rust controller for Kubernetes
  7. Rust and the JVM
  8. diceroller, a sample Rust project
  9. Rust’s Vector (this post)

Here's the diagram we will dive into:

Posted on

diceroller, A Sample Rust Project

For me, the best learning process is regularly switching between learning and doing, theory and practice. The last post was research; hence, this one will be coding.

I've been a player of Role-Playing Games since I was 11. Of course, I've played Dungeons & Dragons (mainly the so-called Advanced Edition), but after a few years, I've taken upon Champions and its HERO system. The system is based on points allotment and allows virtually everything regarding a character's abilities. For a brief description of the system, please check this brilliant albeit brief Stack Exchange answer. I've developed a sample application to handle (a part of) the damage generation subsystem for this post.

Posted on

A Rust Controller for Kubernetes

To teach myself Kubernetes in general and controllers in particular, I previously developed one in Java. This week, I decided to do the same in Rust by following the same steps I did.

  1. My First Cup of Rust
  2. My Second Cup of Rust
  3. The Rustlings Exercises - Part 1
  4. The Rustlings Exercises - Part 2
  5. Rust on the Front-End
  6. A Rust Controller for Kubernetes (this post)

The Guiding Principle

The guiding principle is creating a Kubernetes controller that watches pods' lifecycle and injects a sidecar into them. When Kubernetes schedules the pod, the controller schedules the sidecar; when it deletes the former, it deletes the latter as well.

Posted on

Rust on the Front-End [Video]

Up until now, JavaScript has been the only ubiquitous language available in browsers. It has made JavaScript much more popular than its design (and its associated flaws) would have allowed. Consequently:

  • The number of JavaScript developers has grown tremendously and steadily,
  • The ecosystem around front-end JavaScript has become more extensive and much more complex,
  • The pace of changes has increased so that developers complain about JavaScript fatigue,
  • Interestingly enough, JavaScript sneaked on the back-end via Node.js,
  • etc.

I don't want to start a holy war about the merits of JavaScript, but IMHO, it only survived this far because of its role in browsers. In particular, current architectures move the responsibility of executing the code from the server to the client. It puts a lot of strain on the latter. There are not many ways to improve performance: either buy more powerful (and expensive!) client machines or make the JavaScript engines better.

Posted on

BlockHound: How it Works

One of the talks in my current portfolio is Migrating from Imperative to Reactive. The talk is based on a demo migrating from Spring WebMVC to Spring WebFlux in a step-by-step approach. One of the steps involves installing BlockHound: it allows to check whether a blocking call occurs in a thread it shouldn't happen and throws an exception at runtime when it happens.

I've presented this talk several times in the previous week, both in its Java version and its Kotlin one. One such presentation was at Javaday Istanbul. After the talk, one of the questions I received was, "How does BlockHound work?" I admit that at the time, I couldn't remember. After the surprise had passed, but too late, I remembered it involved a Java agent. But I wanted to go down the rabbit hole.

Posted on

My First Cup of Rust

It all started with an informal chat with my friend Anthony. We were talking about languages, and I said that I preferred compiled ones. He then went on to mention Rust. We admitted that we were too afraid to learn it because of its perceived complexity.

After the chat, I thought about it, and I wondered why I didn't check by myself. I did. And I became interested.

Posted on

Hacking Third-Party APIs on the JVM

The JVM ecosystem is mature and offers plenty of libraries, so you don't need to reinvent the wheel. Basic — and not so basic — functionalities are just a dependency away. Sometimes, however, the dependency and your use-case are slightly misaligned.

The correct way to fix this would be to create a Pull Request. But your deadline is tomorrow: you need to make it work now! It's time to hack the provided API.

Posted on

A Real-World Example of a Stream Collector

Java Stream's Collectors methods fit most use-cases. They allow returning either a Collection or a scalar. For the former, you use one of the toXXX() method, for the latter, one of the reducing() one.

Let's imagine an e-commerce platform that implements a shopping cart. The cart is modeled as the following:

Posted on

A Look at Kotlin’s Delegation

Kotlin offers many exciting features. In general, developers tend to cite null safety as their favorite. For me, it's function extensions. But delegation comes a close second.

The Delegation Pattern

The delegation pattern is described in the GoF book:

Posted on

Hazelcast, From Embedded to Client-Server

Java developers are particularly spoiled when using Hazelcast. Because Hazelcast is developed in Java, it's available as a JAR, and we can integrate it as a library in our application. Just add it to the application's classpath, start a node, and we're good to go. However, I believe that once you start relying on Hazelcast as a critical infrastructure component, embedding limits your options. In this post, I'd like to dive a bit deeper into the subject.

Starting With Embedded

As mentioned above, the easiest way for Java developers to start their journey using Hazelcast is to embed it in their application like any other library. During the application startup lifecycle, we just have to call Hazelcast.newHazelcastInstance(): this will start a new Hazelcast node in the currently running JVM. Because of Hazelcast auto-discovery capabilities, without further configuration, nodes will discover each other and form a cluster. In a couple of minutes of development time, we can create a distributed In-Memory Data Grid. Hard to do better in terms of Developer Experience! 

Posted on

Changing a Field’s Type in Recent JDKs

A couple of years ago, I attended a talk of my former colleague (but still friend) Volker Simonis. It gave me the idea to dig a bit into the subject of how to secure the JVM. From the material, I created a series of blog posts as well as a talk.

From that point on, I submitted the talk at meetups and conferences, where it was well-received. Because I like to explore different areas, I stopped to submit other proposals. Still, the talk is in my portfolio, and it was requested again in 2021. I have already presented it twice since the beginning of the year at the time of this writing.