Thoughts on agile software development
Jens 
Die Holidays Bibliothek aus dem Beitrag Kalenderspielereien mit Java hat schon seit geraumer Zeit keine Aktualisierung erfahren. Daher sollen einige Methoden hinzuzugefügt werden um den Umgang mit Werktagen zu vereinfachen.
In mancher Java Anwendung befinden sich Legacy Code Einschlüsse um JDBC Anfragen, die nicht mehr zeitgemäß erscheinen. Häufig wünscht sich der Entwickler, den recht plumpen Code durch eine elegante Stream Variante zu ersetzen. In dem Beitrag JPA Tabellen mit reservierten Nummernkreisen wurden IDs aus einer Tabelle ausgelesen, um den größten gefundenen Wert als Basis für zukünftige IDs zu nutzen. Der ursprüngliche Code arbeitet mit einer while-Schleife, die über ein ResultSet iteriert.
Wer sich für das T-Shirt “YOU ARE MY IMPEDIMENT” begeistert, kann es ab jetzt wieder direkt über diese Seite erwerben. Natürlich sind im Shop auch andere Produkte erhältlich. Einfach mal stöbern.
Viele Konzepte sind so einfach, dass man kaum Ideen findet um einen neuen Blickwinkel aufzuzeigen. Leider gibt es aber auch kein Konzept, das zu einfach für eine fehlerhafte Nutzung wäre.
Kanban ist eine beliebte Methode in der IT, weil ihre Einführung trivial ist und ein Nutzen schnell erkennbar wird.
Die Fehlerbehandlung in der Programmiersprache Java folgt einigen einfachen aber mächtigen Mustern. Dennoch zeigt sich immer wieder die Tendenz, auf erschreckende Weise davon abzuweichen.
Manche Probleme werden von den Kollegen nur erkannt, wenn wir für sie drastische Vergleiche entwerfen. Ohne die Bilder einer anderen Gefahr vor dem inneren Auge, werden organisatorische Defizite häufig mit einem Achselzucken hingenommen. Wer kennt ihn nicht Smaug den Drachen? In meiner Jugend wussten tatsächlich nur die Liebhaber von Sagen und phantastischen Geschichten von ihm, viele von ihnen genauso computerbegeistert wie der Autor. Seitdem der Hobbit nun, in viel zu vielen Teilen, verfilmt wurde, ist die Geschichte von Smaug ins kollektive Gedächtnis gewandert.
“Beziehungen bleiben bestehen aber Bedürfnisse ändern sich”. So oder so ähnlich heißt es in einer schlüpfrigen Fernsehwerbung zu später Stunde. Bei Microservices finden sich aber tatsächlich immer wieder Situationen, bei denen zwei Microservices besser harmonieren, wenn ein dritter involviert ist.
Wie auch der vorherigen Beitrag handelt dieser über Microservices als Architekturkonzept und die dort verwendeten Design Pattern. Bei dem Microservice Pattern Domain Events handelt es sich um die Nutzung von fachlichen Ereignisse aus dem Bereich Domain-Driven Design. Die Microservices kommunizieren also nicht nur über direkten Nachrichtenaustausch mit ihnen bekannten Services, sondern sie signalisieren auch Änderungen an entkoppelte, ihnen unbekannte Services.
Mikroservices stellen ein eigenes Architekturkonzept dar, mit denen Anwendungen dezentral und entkoppelt entwickelt und betrieben werden können. Eine große Anzahl von Design Pattern macht es den Entwicklern dabei einfach, gute Architekturen zu erstellen. Die Mikroservices Architektur wirkt sich jedoch nicht nur auf die Software aus, sondern bietet auch viel Potenzial um die Arbeit der Teams zu verbessern. Wie dies im speziellen aussehen kann soll an dem sehr grundlegenden Pattern Database Per Service dargestellt werden.
Ein großes Missverständnis bei der Verwendung von Microservices, ist die Annahme, es wären einfach nur sehr kleine Services. Diese Herangehensweise führt zwar schnell zu beträchtlichen Erfolgen, sie fördert aber mittel- und langfristig Fehler in ihrer Betrachtung, Verwendung und Entwicklung.