Unnecessary Unit Tests

The First Ideal: Locality and Simplicity

Hi,

Ich habe mal ein Backend zu zweit entwickelt. Es war das Backend von Sunrise Village .

Bereits in der Pre-production schloss ich mich dem Team an. Gemeinsam mit meinem damaligen Kollegen. Über drei Jahre war das unser Backendteam.

Die anderen Teams waren größer. Wir hatten bis zu 8 Frontendentwickler, ähnlich viele Artists, zwei Gamedesigner, Productowner, Productmanager und 2 Testautomatisierer.

Und selbst, dass wir nur zu zweit waren, war eigentlich zu viel. Wir waren es zur Risikominimierung - falls einer ausfällt.

Marcus Held

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

Hi,

“Ich glaube Loom wird reactive programming vernichten”

Dieser Satz stammt von Brian Goetz .

Weißt du wer das ist? Brian ist seit 13 Jahren Java Language Architect bei Oracle.

Aus seiner Feder stammt “Java Concurrency in Practice” - eines der Standardwerke für jeden Java Entwickler .

Er war es auch, der JSR-335 - Lambda Expressions - in die Sprache brachte.

Was Brian sagt hat Substanz. Du findest auf der ganzen Welt wohl kaum jemanden, der einen besseren Ausblick auf die Zukunft von Java und dessen Ökosystem geben kann.

Marcus Held

Der Hi/Lo-Algorithmus in Hibernate: Optimierung der Datenbank-Identifikatorgenerierung

In der Welt der Persistenz auf der JVM hat Hibernate einen festen Platz. Als eines der populärsten Frameworks für die Persistierung von Daten bietet es eine Vielzahl an Möglichkeiten, um Entwicklern das Leben einfacher zu machen. Eine dieser Möglichkeiten ist der Hi/Lo-Algorithmus, eine Datenbank-Identifikatorgenerierungsstrategie, die es ermöglicht, die Anzahl der Datenbankaufrufe zu reduzieren, wenn neue Entitäten persistiert werden.

Die Herausforderung der Identifikatorgenerierung

Bevor wir in den Hi/Lo-Algorithmus eintauchen, wollen wir uns kurz die Herausforderung der Identifikatorgenerierung in einer Datenbank anschauen. Jede Entität in einer Datenbank benötigt einen eindeutigen Identifier (oft als ID bezeichnet), um sie von anderen Entitäten zu unterscheiden. Bei jedem Einfügen einer neuen Entität in die Datenbank wird bei numerischen IDs normalerweise die Sequenz auf der Datenbank abgefragt, um die nächste ID zu erhalten. Dies kann jedoch zu einer hohen Anzahl von Datenbankaufrufen führen, insbesondere wenn viele neue Entitäten persistiert werden.

Marcus Held

Surprising Documentation

Hi,

Klassenkommentare, Architekturdokumentation, Methodenkommentare, API-Dokumentation, Inlinekommentare, Featuredokumentation, Wireframes, Entity-Releationship-Diagramme, Use-Case-Diagramme, Processdokumentation, End-User-Dokumentation….

Es gibt so viele Dinge die man dokumentieren kann. Aber welche brauche ich wirklich?

Dokumentation schreibt sich nicht von alleine. Jemand muss sich dafür die Zeit nehmen. Und damit sie auch wirklich Mehrwert bringt muss sie gut geschrieben, möglichst vollständig und fokussiert sein. Das kann nicht jeder.

In großen Konzernen - mit tausenden Mitarbeitern - wird viel dokumentiert. Es gibt Softwarearchitekten, die die Zeit und Ausbildung haben gute Dokumentation zu schreiben. Es gibt so viele Entwickler, dass genügend Zeit eingeräumt wird den Code zu dokumentieren. Und technischer Autoren verfassen in höchster Qualität die End-User-Dokumentation.

Marcus Held

Vermeidung mehrfacher Datenabrufe durch den First-Level-Cache in Spring Data JPA

Wenn du dich mit der Backendentwicklung auf der JVM befasst, wirst du sicherlich auf die Java Persistence API (JPA) stoßen. Ein bekanntes Implementierungsframework dafür ist Hibernate. In diesem Artikel zeigen wir dir, wie du in Spring Data JPA mit caching die Performance deiner Anwendung optimieren kannst, indem du verhinderst, dass gleiche Ressourcen mehrfach abgerufen werden.

Was ist der First-Level-Cache?

Spring Data JPA verwendet Hibernate als Standard-ORM (Object-Relational Mapping), das einen eingebauten First-Level-Cache anbietet. Jede Session hat ihren eigenen Cache, den wir als First-Level-Cache bezeichnen. Jedes Mal, wenn du ein Objekt (oder genauer gesagt eine Entity-Instanz) aus der Datenbank abrufst, wird es zuerst im First-Level-Cache gespeichert. Bei wiederholtem Abrufen desselben Objekts wird es direkt aus dem Cache und nicht aus der Datenbank geholt. Das kann zur Datenwiederholung führen und die Performance beeinträchtigen.

Marcus Held