Thoughts on agile software development
Die Einführung der Generics in Java 8 hat zur einigen eigentümlichen Konsequenzen geführt. Die meisten dieser Konsequenzen fußen auf dem Konzept der Type Erasure. Die Generics sind nur Bestandteil der Java Sprache und werden demzufolge nur vom Java Compiler beachtet. Der compilierte Code kennt, salopp gesprochen, keine generische Typen sondern operiert auf dem vermuteten Basistypen der Generics.
Nach einigen Beiträgen zu Microservices soll in diesem Beitrag ein wenig über die Schattenseiten der Technologie berichtet werden. Insbesondere über Bad-Smells und Anti-Pattern, den falschen Lösungsansätzen, bei der Entwicklung eigener Microservices.
Hin und wieder entdeckt man als Software Entwickler ein Feature in einer Bibliothek wieder, dass man schon zweimal vergessen hat. Wenn man dieses wiederentdeckte Wissen mit einem Kollegen teilen kann, dann ist es nicht nur schön sondern verbessert auch noch die Qualität der täglichen Arbeit.
Bei der Weiterentwicklung einer REST API kommt es hin und wieder zu veränderten Darstellungen der Attribute. Je nachdem wie der Versionierung der eigenen API gestaltet wurden, ergeben sich eine Reihe von Möglichkeiten mit geänderten Attributen umzugehen.
Bei der Entwicklung von Software handelt es sich immer um die Formulierung von Lösungen in Form von Software. Söll die Software eine gute Lösung für ein Problem sein, dann sind Design Pattern eine gute Hilfe. Design Pattern sind Musterlösungen für typische Probleme in der Softwareentwicklung. Wer sie kennt, entwickelt nicht nur Software, die eine etablierte Lösungsstrategie verfolgt, sondern erhöht auch den Wiedererkennungswert für Kollegen und reduziert die Entwicklungszeit.
Für jedes Design Pattern gibt es ein entsprechendes Problem und beim Memento Pattern ist es die Frage, wie der Zustand eines Objekts zwischengespeichert werden kann, ohne seine interne Struktur zu entblößen.
Fasst drei Jahre nach dem ersten Beitrag zum eigenen API MarktDown ergibt sich ein zweiter Beitrag zum Thema. Bei der Durchsicht der eigenen Projekte fiel auf, dass in dem Projekt rest-markdown-plugin noch immer FreeMarker als Template-Engine verwendet wurde. Die erste Ad-Hoc Umstellung der Template-Engine auf FreshMarker scheiterte jedoch kläglich.
Wer sich an die Aufzählung der unterstützen temporalen Datentypen erinnert, wird diverse neue Klassen wie Instant, ZonedDateTime oder OffsetDateTime vermissen. In diesem Beitrag werden zwei von ihnen in die Gruppe der unterstützen Datentypen aufgenommen. Bevor die Implementierung dieser Erweiterung vorgestellt wird, ein paar Worte zu den temporalen Java Standardklassen.
Einer der Gründe für die Entwicklung der FreshMarker Bibliothek, war die fehlende Unterstützung der Java Time API in FreeMarker. Daher existierte schon in der ersten Implementierung neben der Unterstützung für java.util.Date, java.sql.Date und java.sql.Time auch eine Unterstützung für java.time.LocalDateTime, java.time.LocalDate und java.time.LocalTime. In diesem Beitrag wird die Formatierung für alle temporalen Typen verbessert. Bislang beherrschte FreshMarker nur die Standarddarstellung und eine Computer Audience Darstellung.
Nachdem im vorherigen Beitrag zum Thema, die Prüfung der deutschen IBAN und BIC verbessert wurde, rundet dieser Beitrag die Validierung ab.
Im ersten Teil zu der IBAN und BIC Validierung wurden erste Implementierungen vorgestellt um die syntaktische Korrektheit von IBAN und BIC zu prüfen und bei der IBAN zusätzlich die Prüfsumme zu nutzen. In diesem Beitrag sollen zusätzliche landesspezifische Eigenschaften genutzt werden. Insbesondere die Informationen der Deutschen Bundesbank zu den deutschen Geldinstituten.