Mittelstand, Finger weg von Microservices!

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

Double-Entry Bookkeeping

Hi,

Ein Fehler in der Buchhaltung kann teuer sein. Gerade in großen Unternehmen, in denen es sehr viele Transaktionen gibt, ist es leicht eine zu übersehen.

Und wenn das passiert, dann merke ich es noch nicht einmal. Vielleicht steht das Unternehmen viel besser da, als es die Bücher hergeben? Oder vielleicht ist es eigentlich unprofitabel?

Die Kaufleute haben im 13 Jahrhundert das Problem erkannt. Es musste ein System gefunden werden, dass Fehler unwahrscheinlicher macht. Es wurde die doppelte Buchhaltung erfunden.

Marcus Held