Deutsche Feiertage 2022
Der Blog-Beitrag Kalenderspielereien mit Java – iCalendar stellte die deutschen Feiertage für das Jahr 2020 im iCal Format bereit. Hier nun der Download der Feiertage für das Jahr 2022.
Thoughts on agile software development
Der Blog-Beitrag Kalenderspielereien mit Java – iCalendar stellte die deutschen Feiertage für das Jahr 2020 im iCal Format bereit. Hier nun der Download der Feiertage für das Jahr 2022.
Im ersten Teil dieses Beitrags wurde ein Ansatz zur Validierung von Datumsangaben vorgestellt, der auf der Angabe von expliziten Zeitfenstern beruht. Damit keine Angaben weit in der Zukunft getätigt werden können, wird der Zeitraum direkt in der Validierungs-Annotation beschränkt.
Die erste Implementierung hatte den Nachteil, dass sie nur für den Type LocalDate bereitstand. In diesem Beitrag wird beschrieben, welche Änderungen nötig sind um auch weitere Typen zu unterstützen. Zusätzlich werden auch Zeitfenster in die Vergangenheit implementiert.
Der Bean Validation 2.0 (JSR380) Framework nimmt dem Java Entwickler viel Arbeit ab. Die Prüfung auf valide Daten reduziert sich mittlerweile auf einige Annotationen an den zu prüfenden Konstrukten. Auch im Bereich der Datumsprüfungen gibt es reichlich Unterstützung. Aber manchmal kann es ein wenig mehr sein.
Bei der Diskussion welche Methodik am besten geeignet ist, um die Softwarequalität von Legacy Software zu verbessern, wird häufig das Pfadfinder Prinzip hochgehalten. Die Vertreter diese Methodik möchten die Software in kleinen Refactoring Schritten während der Implementierung neuer Features verbessern. Die Idee ist einfach und einleuchtend, denn wenn ich sowieso gerade zur Stelle bin, kann ich in der Umgebung auch gleich aufräumen.
Mit Spring Boot können eigene REST Services schnell erstellt werden. Die dabei notwendige Validierung der Parameter ist mit dem Bean Validation Framework (JSR 380) auch in Windeseile hinzugefügt. Manchmal ist es aber notwendig verschiedene Parameter gegeneinander zu prüfen, dann reichen die Standardwerkzeuge nicht mehr aus und eigene Validatoren müssen erstellt werden. Anhand eines kleines Beispiel zeigt dieser Beitrag, wie einfach das geht.
Das Zitat „Die Unit Tests schreibe ich immer zum Schluss“ hat vermutlich schon jeder Entwickler von einem Kollegen hören müssen. Üblicherweise, wenn man bei einem schwerwiegenden Problem während der Implementierung helfen möchte. Ein kurzer Blick auf die Testergebnisse hilft dann enorm. Häufig zeigen die fehlgeschlagenen Unit Test direkt auf das Problem. Fehlen die Unit Tests, dann müssen sich die Entwickler solange durch GIT Historie und Debugger quälen, bis der eingeschleppte Fehler gefunden ist.
Die Bibliothek Mockito ist in der Test-Driven Software Entwicklung kaum noch wegzudenken. Die Möglichkeit komplexe Interaktionen mit APIs durch Mocks simulieren zu lassen, vereinfacht und beschleunigt die Implementierung eigener Anwendungen. Leider gibt es aber immer wieder kleine Stolperfallen in der Verwendung dieses ansonsten hervorragenden Framework.
Der Spring Boot WebClient ist der reaktive, nicht blockierende Alternative zum RestTemplate. Obwohl der WebClient für die Anwendung in reaktiven Anwendungen entworfen wurde, kann er auch in klassischen Anwendungen das RestTemplate ersetzen. Insbesondere die moderne Implementierung und die Fluent API sind es, die den Software Entwickler die Entscheidung für den WebClient leicht machen. Obwohl die Fluent API des WebClient ein Segen für die Entwicklung ist, stellt sie einen Fluch für die Unit Tests da.
Hin und wieder geben aktuelle Diskussionen den Anstoß über gerne und häufig verwendete Begriffe einmal etwas genauer nachzudenken. Im diesem Fall über die Technischen Schulden. Was ist damit gemeint und wie ist mit ihnen umzugehen?