I never moved away from Docker Desktop. For some time, after you use it to build an image, it prints a message: What's Next? View a summary of image vulnerabilities and recommendations → docker scout quickview I decided to give it a try. I’ll use the root commit of my OpenTelemetry tracing demo. Let’s execute the proposed command: docker scout quickview otel-catalog:1.

The idea of bytecode that can run anywhere dates back to the JVM inception (as far as I know). WebAssembly is the new implementation of an old idea. While WebAssembly is meant to run in the browser, Docker recently announced its capability to run WASM code without needing containers. In this post, I want to explore how it can work. Prerequisite Running WebAssembly is a beta feature and requires using containerd.

Last week, I described different techniques to fasten your Maven builds. Today, I’d like to widen the scope and do the same for Maven builds inside Docker. Between each run, we change the source code by adding a single blank line; between each section, we remove all built images, including the intermediate ones that are the results of the multi-stage build. The idea is to avoid reusing a previously built image. Baseline To compute a helpful baseline, we need a sample project.

Since Docker announced that it would remove unused images from Docker Hub, I’ve been interested in listing places where I could host mine. As it’s for personal purposes, I’m interested in free plans. Here’s what I found.

This week, I want to take a break from my Start Rust series and focus on a different subject. I’ve already written about my blogging stack in detail. However, I didn’t touch into one facet, and that facet is how I generate the static pages from Jekyll. As I describe in the blog post, I’ve included quite a couple of customizations. Some of them require external dependencies, such as: A JRE for PlantUML diagrams generationThe graphviz package for the same reasonetc.

If you like cool stories about how an engineer, faced with an impossible problem, overcame all odds and solved it, this post is not for you. This is a story of how I spent a non-trivial amount of time, how I hit a couple of walls, and how I nearly came back to square one. Why do I write it? The first reason is for me: I want to document my journey so if I ever think about trying again in the future, I’ll have some arguments against it.

Containerizing an application based on a 'scripting' language is straightforward. Add the sources, download the dependencies, and you’re good to go. One could say they are WYSIWYR. With compiled languages in general, and Java in particular, things are a bit different. In this post, I’d like to list some alternatives to achieve that.

This post is neither a recommendation, nor even a suggestion. It’s just me toying with an idea: Implement it at your own risk! The main benefit of Docker containers is that they are self-contained. For developers, that means one just needs to inherit from the desired Docker image that contains the necessary required dependencies, and presto, one can build one’s application deliver it to production. Most of the times, the process is pretty straightforward.

It’s hard to ignore Docker nowadays. There are a lot of blog posts available on the Web. The problem is that most always repeat the same. In this post, I’d like to focus on one directive that I find overlooked via a use-case: it is Java specific, but the parallel can be easily drawn to other tech stacks. The problem The situation is the following: as a developer, I’d like to use Docker as a way to package a JAR from the sources of my application.

Since already some years, this site uses the Jekyll static site generator. Generating the complete site takes about 15 minutes. Some time ago, I decided to setup Gulp to minimize HTML in order to speed up page view for readers. This change added about 10 minutes to the build time, for a total of ~25 minutes, which is a long time…​ too long. I wanted to decrease the build time, so I decided to play around. The initial state A Docker image is used to build the site.

Two weeks ago, we studied how to replace desktop Java apps with Java webapps. Now is the time to think about distributing such desktop webapps. The current trend now is to use Docker. I assume readers are at least familiar with the technology. The most straightforward way is to create a WAR and deliver it inside a Tomcat image. Another option is to create a fat JAR with Tomcat embedded as per the previous post, and run it inside a image with the JRE only.

It sometimes happen that after a few years, an app is stable enough that it gets into hibernating mode. Though it’s used and useful, there are no changes to it and it happily runs its life. Then, after a while, someone decides to add some new features again. Apart from simple things such as locating the sources, one of the most important thing is to be able to build the app. Though it may seem trivial, there are some things to think about.

Since the Docker 'revolution', I’ve been interested in creating a Dockefile for Spring applications. I’m far from an ardent practitioner, but the principle of creating the Dockerfile is dead simple. As in Java - or probably any programming language, however, while it’s easy to achieve something that works, it’s much harder to create something that works well.

I’m a huge Vaadin fan and I’ve created a Github workshop I can demo at conferences. A common issue with such kind of workshops is that attendees have to prepare their workstations in advance…​ and there’s always a significant part of them that comes with not everything ready.