Too Big, Too Small, Just Right

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

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

Nobody Talks About Project Loom

Hi,

Wieso spricht keiner über Project Loom?

Auf der JVM steht uns einer der größten Änderungen seit Jahren bevor.

Und sie beeinflusst massiv wie wir arbeiten.

Asynchronität ist schwer. Es muss über so viel nachgedacht werden:

Wie konfiguriere ich meinen Threadpool? Hat der Codepath mehr wait-time oder rechnet er lange? Und wie groß sollte die Queue vor dem Threadpool sein? Sind Spikes in dem Codepath zu erwarten?

Und wie bekomme ich eigentlich meine globalen State, wie den SecurityContext oder den MDC darüber?

Marcus Held