Until recently I’ve found unsubscribing to be a confusing subject. Apparently, you have to unsubscribe if you want to avoid memory leaks. But NOT doing so doesn’t always result in a memory leak. So what causes these leaks and how can we avoid them?

Building Event Driven systems is great, but not all systems are Event Driven. Communication with those systems can be via HTTP and those systems may not be able to respond quickly to a request, taking up to minutes to serve a response.

Are there tools to mock such a situation to be used for testing?

In every organization and in every team, I run into one or two customs that people tell me are part of "Scrum by the book", that aren’t actually in the book.

Locally deployed clusters can be a convenient part of a modern software development cycle, reducing feedback loops and give a developer a useful representation of the live version of an app, even if it’s just a stub. Unfortunately, they have a reputation for eating up your precious resources like they’re mashed taters. Since this year working from a home office has become the norm for many developers around the world. Enter the home desktop to "share the load" with our brave little work laptop. We will form a fellowship with our loyal home desktop, to help us through this new and uncertain adventure. Keep reading to find out how we can take off and escape this "Mount Doom" scenario!

In a previous post we learned how to replace a file in an archive with Gradle. In this blog post we use Maven to achieve the same goal. With Maven we first have to extract the contents of the archive and then assemble a new archive where we use a file replacement to replace an original file from the archive. To extract the contents we use the task unzip with the maven-antrun-plugin. To create a new archive we use the maven-assembly-plugin. The destination directory of the extracted contents is the input fileset for the assembly definition together with the files we want to overwrite. The end result is a new archive with replaced files.

In the following pom.xml we configure the maven-antrun-plugin and maven-assembly-plugin:

Sometimes we might need to replace one or more files in an existing archive file. The archive file could be a zip, jar, war or other archive. Without Gradle we would unpack the archive file, copy our new file into the destination directory of the unpacked archive and archive the directory again. To achieve this with Gradle we can simply create a single task of type Zip. To get the content of the original archive we can use the project.zipTree method. We leave out the file we want to replace and define the new file as replacement. As extra safeguard we can let the tsak fail if duplicate files are in the archive, because of our replacement.

The following code shows an example of a task to replace a README file in an archive sample.zip using Groovy and Kotlin DSL. First the Groovy DSL:

At my current customer we use Github a lot. Everything requires a review via a Pull Request. It is sometimes tedious to switch from your IDE or terminal to the browser while creating a PR. Github has a command line utility called gh which you can use to automatically create a PR from the command line. It has lots of extra stuff as well, such as downloading releases, viewing issues, creating gists, cloning repo’s and code completion.

Start by following the installation steps in https://github.com/cli/cli to install the gh binary. There are packages for all operating systems.

Great to be the one kicking off our yearly blog festival Blogtober! This first blog is not particularly technical, but this subject has been the most prominent thing on my mind during the last 6 months. Connection with colleagues and sharing knowledge is part of our DNA at JDriven, better yet, it is part of our vision as a company. Throughout the years we gathered lots of experience in how we share our knowledge with the community. But this was always in a world without social distancing and other connection limitations.

First paragraph.

My post with code

As more and more teams and companies adopt Apache Kafka, you can find yourself wanting to share data via replication of one or more topics from one cluster to another. While replication of an entire cluster with all of it’s topics as a means of failover can be achieved with tools such as Mirror Maker and Confluent Replicator, for replication of a single topic there are fewer examples. Even more so when the source topic is serialized with Avro, with the schema stored in Confluent Schema Registry.

Here we present a minimal consumer that replicates a single Avro serialized Kafka topic from one cluster to another, while ensuring (only) the necessary Avro schema is registered in the target cluster Schema Registry.