When bytes
meet Mike

While browsing Twitter a few days ago, I’ve been reminded about a quite controversial topic in the Java community, which (apparently) still is using interface default methods. To be honest, I’ve been a bit skeptical as well when I’ve first seen them coming as a part of Java 8. However, today I’ll write a few words in defense of default methods, as when used carefully, they can turn out to be extremely handy.

The world has changed quite a lot since 1999 when Eric Brewer formulated his famous conjecture, known as the CAP Theorem today. Back then, the systems were running mostly on a self-hosted and rather expensive infrastructure, often related to the software components in use (due to licensing, etc.). A proper understanding of availability & consistency trade-offs in the presence of network partitions was simply yet another responsibility on the list.

There seems to be a lot of interest in improving application startup time these days, driven by the discussions on languages and technologies (like Go, Node, or GraalVM), that provide almost instant startup for serverless functions (a.k.a. lambdas) being run in the cloud. However, such a speedup brings benefits to other types of processing as well. In this post, I’d like to present a different perspective on the topic of application startup time.

Syntactic sugar (like the introduction of var) is often not enough to convince somebody (especially non-developer) to move forward. This is one of the reasons why Java 8, almost 7 years after its first release, is still widely used. However, many things have improved apart from the syntax. When taking all of them into account, it may turn out that you can’t afford to run Java 8 anymore. And no, I don’t mean migrating the code, but simply updating the JVM used as a runtime!

What could be kind of surprise even for some experienced Java programmers, the java.util.Stream interface extends java.lang.AutoCloseable. This (in theory) puts it on par with files, DB connections, and other resources requiring manual closing. Should we close all our Streams in the same way as any other resources? In this post, I’d like to explain which Streams have to be closed and how the closing actually works. We will also go through some of the interesting under-documented properties of this feature.

Apache Kafka has been designed with scalability and high-performance in mind. Thanks to its architecture and unique ordering guarantees (only within the topic’s partition), it is able to easily scale to millions of messages. However, there are some specific situations when using a topic with just one partition (despite being against mentioned features) might be a valid and simple solution to some complex problems of the distributed world. In this post, I’d like to describe the so-called single-partition topic pattern and to list some valid use cases for it.

The end of the year is an especially intensive recruitment season for many IT companies & software houses. This does not mean that only HR departments have their hands (and calendars) full. As one of the last steps before offering (or not) a job, a technical interview has to take place. Selected engineers, previously busy with technical stuff, have to now become recruiters, verifying people’s skills and experience. And that’s quite of a challenge!

In this post, I’d like to describe the issue I’ve recently encountered when using Helm umbrella charts. Long story short, it turned out that subcharts are not completely isolated from each other, contrary to what we probably would expect. This feature has also some important consequences for building umbrella charts and combining different dependencies into one parent chart, which I want to outline as well. Umbrella charts basics Helm umbrella charts are an easy and powerful way of installing multiple components as a single one.

People are using all their senses for recognition. Just think about how many jingles, slogans, images, or even actor faces unequivocally remind us of something. They are consistently building what we call a brand. It’s not a coincidence by the way - it’s called multisensory marketing. Software engineering loves consistency too - not only when ACID comes to play, but also in terms of technical content. Interestingly, only some of the tech companies I know managed to build a consistent, nice to look at visual identification or technical brand (surprisingly, the budget often seems not to be a reason for that).

At the end of 2018, I had a pleasure to give a talk at Testwarez - the oldest testing-oriented conference organized in Poland. The recording recently appeared on YouTube, so I decided to take this opportunity to figure out what has changed through the past few months in terms of tools that I presented. The goal of my talk was to present some practices and open source tools for improving the overall security of Java-based projects.