Docker compose introduced a new feature in a recent update called the compose menu. It adds an extra line in the terminal while running docker compose up in the attached mode, i.e. without the -d flag.

Image source: https://github.com/docker/for-win/issues/14021#issuecomment-2161370349

The issue is that the menu breaks the active session. In my case, after stopping the containers, I could not see what I was typing in the terminal, as if I was entering a password: the text was not visible.

As this menu doesn't bring anything useful to the table, I figured I should be able to disable it. According to the documentation, there are two ways to turn it off.

I want to recommend a couple of courses on Udemy that I took over the last couple of months. Both helped me gain confidence and knowledge in tools that I use every day: Git and Docker.

Music streaming services provide us access to huge libraries, which is great! Algorithms study what we like and offer useful recommendations or let us discover something entirely new.

However, we can only access what has been officially released. Some "live in ${city.name}" DVD release that you enjoy might not be available on a streaming service. Occasionally, artists and labels end up in legal battles, and the content that was released in the '80s and '90s suddenly can't be distributed anymore. Over time, I started to notice that a playlist with my favorite music lost at least a third of the tracks I liked to listen to! That makes other sources of obtaining music relevant again.

YouTube is one of them. The quality is not fantastic due to irreversible compression, but there are so many live recordings, obscure releases, and covers that I find it worth it. As I store music on my home server, I needed a solution that wouldn't pollute it with hundreds and hundreds of packages. Yes, I'm looking at you, ffmpeg! Probably most tools that can download and process videos from YouTube depend on ffmpeg.

So if you too want to utilize yt-dlp in an isolated environment, I can offer dockerization!

To no one's surprise, posting regularly to a blog when you have a job and when you don't are two different things. Nevertheless, I'm trying to reincorporate writing into my daily routine. If you're reading this, then I have succeeded! In the previous entry, I briefly described that I settled on a Go backend and a React web app for this site, explaining how code generation based on the OpenAPI specification simplifies the synchronization of any changes between the two.

Once the code is written and tested, it's time to deploy it to my VPS. I used a couple of tools for that, with the actual commands stored in Makefiles. For the Go service, it looked like this:

1. Build a new Docker image.
2. Save it as a tar.gz archive.
3. Copy it to a remote server using scp.
4. Load this image to Docker.
5. Update the running container.

While I believe there's nothing wrong with this approach given the nature of the project, I wanted to switch to GitHub Actions and Packages. That would eradicate the need to define deployment properties on every machine where I code, let alone maintaining them up to date if. Moreover, even though the exact tools differ from company to company, this approach would be much closer to what a real business would do with their product. In other words, besides the personal interest, it is relevant to my job!

The transition was rather simple. I was already building Docker images, so all I had to do was to move this part to GitHub and push images to their registry. Here, I want to document what I did and think about what can be done next.

Testcontainers is a great tool for managing external services required for the proper functioning of an entire application or its components during testing. It automatically deploys these services before a test begins and then stops them once testing is over. This simplifies the process of running tests across multiple environments.

While working on integration tests for the service behind this blog, I stumbled upon an issue. It lies on the border between Testcontainers and Spring. When executing a single test or an entire class, everything worked as expected. But when executing multiple test classes (e.g. with ./gradlew test), the database became inaccessible.

In this post I'm exploring one of the possible solutions to this issue.