Leider war mir mein altes Mountainbike schon lange zu klein. Auch gibt es durch Kinder auch nicht mehr die Zeit, wo man einen ganzen Tag etwas macht. Daher war die Idee geboren: ich brauche etwas für die schnelle Tour von der Haustür. Für den Wienerwald tut es aber auch ein Hardtail, weil ich am Trail fahren weniger interessiert bin. Carbon kam für mich nicht in Frage. Aluminium ist nett. Aber “steel is real”. Die Community um Stahlrahmen ist Gott sei Dank sehr groß. E-Bike wollte ich auch keines - also brauchte ich eine gute Übersetzung, um auch längere Anstiege gut fahren zu können. Man wird im Netz 1 Million Diskussionen über dieses Thema finden: Single-Speed Ja order Nein. Fakt ist: beide Systeme haben Vor- und Nachteile. Mögen die Vorteile beim Single-Speed überwiegen - allerdings hat ein Umwerfer eben auch Vorteile: eine feinere Übersetzung.

Ein kurzer Ausflug nach Nizza, um den Geburtstag meiner Frau zu feiern und den Karnevalsumzug zu besuchen. Auch gab es noch in Menton. Beides lohnt sich. Nizza Nizza ist eine schöne Stadt - aber es gibt nicht die “Schlemmermeile”. Da muss man schon einwenig suchen …

AVRO ist derzeit ein sehr populäres Serialisierungs-Framework. Dank Schemaregistry für Enterprise-Anforderungen bestens gerüstet. Es macht Sinn, die generierten Klassen im Code zu verwenden - allerdings ist der Code dann oft mit Zusatzcode zugepflastert, der mit der generierten Klasse interagiert, obwohl die Funktionalität eigentlich besser in die integrierte Klasse passen würde. Ein kurzer Exkurs: Große Schemas verwalten Ein Finding war, dass komplexe Schemas in einer *.avsc File wenig Sinn machen. Die Herausforderung ist, dass beim ersten Vorkommnis ein record typ definiert wird und bei weiterer Verwendung nur mehr referenziert wird – das ist echt mühsam.

Microservices sind ein beliebtes Tool, um komplexe Domänen zu zerteilen. Doch am Ende des Tages macht die Entscheidung des übermäßigen Einsatzes – in manchen Fällen – dann mehr Kopfweh als Nutzen. Vor Kurzem ist mir dabei folgendes Beispiel im Zuge einer Diskussion in den Sinn gekommen: Schauen wir uns einen Teil eines Webshops an: Order Management mit der Aufgabe den Bestellvorgang abzuwickeln Pay Service mit der Aufgabe der Bezahlung Neben fachlichen Aspekten, die für das Schneiden wichtig sind, welche Eigenschaft sind noch wichtig? Stabile Interfaces. Schaut man sich diese an, so merkt man, dass diese relativ einfach sind und eigentlich über die Zeit hinweg stabil sein sollten: Pay Service: Input Parameter: Geldbetrag

Wann macht Table-Partioning Sinn? Vor kurzem hatte ich die Aufgabe, eine Liste aus Rechnungen filterbar zu machen – das schwierige dabei war, dass die Anzahl der Rechnungen nicht bekannt ist und diese auch noch hierarchisch waren (1 Rechnung hat 0..n Positionen – wobei die Positionen von unterschiedlichem Typ sein können). Ebenfalls war die Anforderung “über Jahre hinweg eine stabile Performance zu haben”. Herausforderung 1: Die Pagination in der Übersichtsliste von Rechnungen ist auf der Rechnung – d.h. 10 Element auf der Seite entspricht 10 Rechnungen mit 0..n Positionen. Was bei großen Tabelle gut funktioniert, ist das Suchen nach gewissen Kriterien: e.g. gib mir alle Positionen mit der SomeValue = 123:

Wenn man im Projekt die Situation hat, dass man z.B. zwei unterschiedliche Personen hat, welche einerseits den OpenAPI Contract schreiben und anderseits implementieren, macht es Sinn, den Contract-First Approch zu verfolgen. Bei .NET geht das nicht so out-of-the-box, wie z.B. bei Spring mit Maven. Schritt 1: NSwag Studio laden Das neueste NSwag Studio kann man von hier beziehen: https://github.com/RicoSuter/NSwag/releases. In NSwag kann man den OpenAPI Contract pasten und on-the-fly generieren lassen. Ein gutes Beispiel bekommt man hier: https://editor-next.swagger.io/

Bei Domain-Driven-Design gibt es zwei Flughöhen: Strategic: Hier befasst man sich mit dem „schneiden“ der Domänen Tactical: Hier geht es bis in die Implementierung Ich möchte meine Gedanken zu Tactical zu Blatt bringen. Analyse von Aggregaten Aggregate umschließen jene Entitäten, welche eine atomare Einheit bilden sollen. Das hört sich auf den ersten Blick nutzlos an – aber in fast allen Applikationen muss man von parallelem arbeiten an einem Datensatz durch mehrere Personen ausgehen. Und hier ist das Thema Konsistenz dann ein großes Thema.

Welche Funktionalität ist in meiner Software? Diese Frage ist oft in agilen Projekten nicht einfach zu beantworten – zumindest seriös. Ist das Benutzerhandbuch die einzig valide Quelle? Folgende Vorgehensweise habe ich kennengelernt (es gibt auch viele andere): 1. User-Story Map Als erstes versucht man die User-Stories zu priorisieren. Da kann eine User-Story Map helfen, um eine gute End-to-End-Sicht zu bekommen. Wichtig ist nur zu verstehen: Man soll nicht versuchen, alles in eine User-Story Map zu pressen – man kann ohne weiteres mehrere haben.

Die Reise führte uns nach Auvergne. Die beste Verbindung gibt es wieder über VIE nach LYS. Das 40ige Lebensjahr heuer gut gefeiert – der CO2 Fußabdruck ist aber dementsprechend hoch. Die erste Station war in Clermont-Ferrand. Und zwar in einem alten Schloss. Es war ein schöner, großer Garten dabei. Leider war das Haus im Inneren so niedrig, dass man sich 20 Mal am Tag den Schädl angehaut hat. Zähneputzen in 45 Grad Kopfneigung. Aber es ist ein gutes Base-Camp:

Begonnen hat die Reise in Edinburgh Flughafen. Dort haben wir bei Enterprise ein Auto ausgeborgt – wieder über den ÖAMTC. Vorteil: kein Selbstbehalt und gute Konditionen. Mit dem Auto ging es nach Stirling. Das Fahren auf der „falsche“ Seite fühlt sich komisch an – da ich aber sehr wenig fahre, war die Umstellung auch nicht sonderlich groß. In Stirling haben wir in einer AirBnb geschlafen – eigenes Bad und geteilte Küche mit der Bewohnerin. Stirling selbst ist ok – die wichtigsten Geschäfte und eine kleine Essmeile gabs auch. Die Geschäfte waren wichtig, da unser Gepäck mit all dem Gewand in Wien zurückgeblieben ist. Mittwoch geflogen – Samstag bekommen … Idealer Voraussetzungen für einen Wanderurlaub …