Unnecessary Unit Tests

The First Ideal: Locality and Simplicity

Hi,

I once developed a backend with just two engineers. It was the backend for Sunrise Village .

I joined the team already in the pre-production stage, together with my then colleague. For over three years, we were the backend team.

The other teams were larger. We had up to 8 frontend developers, a similar number of artists, two game designers, product owners, product managers, and 2 test automators.

Even the fact that there were only two of us was actually too many. We kept it that way for risk minimization - in case one of us was unavailable.

Marcus Held

"I think Loom is going to kill reactive programming." ~Brian Goetz

Hi,

“I think Loom is going to kill reactive programming.”

This statement comes from Brian Goetz .

Do you know who he is? Brian has been the Java Language Architect at Oracle for 13 years.

He is the author of “Java Concurrency in Practice” - a standard work for every Java developer .

He was also the one who brought JSR-335 - Lambda Expressions - into the language.

What Brian says has substance. You’ll hardly find anyone else in the world who can provide a better outlook on the future of Java and its ecosystem.

Marcus Held

The Hi/Lo Algorithm in Hibernate: Optimizing Database Identifier Generation

In the world of JVM persistence, Hibernate has a firm place. As one of the most popular frameworks for data persistence, it offers a multitude of possibilities to make developers’ lives easier. One of these possibilities is the Hi/Lo algorithm, a database identifier generation strategy that allows reducing the number of database calls when new entities are persisted.

The Challenge of Identifier Generation

Before we dive into the Hi/Lo algorithm, let’s briefly look at the challenge of identifier generation in a database. Every entity in a database needs a unique identifier (often referred to as ID) to distinguish it from other entities. With each insertion of a new entity into the database, the sequence on the database is usually queried to get the next ID for numerical IDs. However, this can lead to a high number of database calls, especially when many new entities are being persisted.

Marcus Held

Surprising Documentation

Hi,

Class comments, architecture documentation, method comments, API documentation, inline comments, feature documentation, wireframes, entity-relationship diagrams, use-case diagrams, process documentation, end-user documentation…

There are so many things one can document. But what do I really need?

Documentation doesn’t write itself. Someone has to take the time. And for it to truly add value, it needs to be well-written, as complete as possible and focused. Not everyone can do that.

In large corporations - with thousands of employees - a lot is documented. There are software architects who have the time and education to write good documentation. There are so many developers that enough time is allocated to document the code. And technical writers produce the highest quality end-user documentation.

Marcus Held

Avoiding Multiple Data Fetches Using the First-Level-Cache in Spring Data JPA

If you’re dealing with backend development on the JVM, you’ll surely come across the Java Persistence API (JPA). A well-known implementation framework for it is Hibernate. In this article, we’ll show you how you can optimize the performance of your application in Spring Data JPA with caching by preventing the same resources from being fetched multiple times.

What is the First-Level-Cache?

Spring Data JPA uses Hibernate as the default ORM (Object-Relational Mapping), which provides an inbuilt First-Level-Cache. Each session has its own cache, which we refer to as the First-Level-Cache. Every time you retrieve an object (or more precisely, an entity instance) from the database, it is first stored in the First-Level-Cache. When retrieving the same object again, it is fetched directly from the cache and not from the database. This can lead to data repetition and impair performance.

Marcus Held