Gedanken zur agilen Softwareentwicklung
Wie man es besser macht
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.
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.
Bei der Erstellung eigner Stammbäume gibt es immer wieder den Wunsch in anderen Datenbeständen nach Familienangehörigen zu suchen. Dabei ergibt sich jedoch das Problem, dann personenbezogene Daten an andere versendet werden müssen.
Das Logging von Web-Anwendungen, bzw. allen Server-Anwendungen ist mit seinen eigenen kleinen Tücken versehen. Die üblichen, mehr oder wenig hilfreichen Log Anweisungen, die sich im Source Code tummeln, sorgen für einen stetigen Strom von Log-Ausgaben. Solange sich die Ausgabe auf einen einzelnen Request bezieht, ist häufig noch sehr gut nachvollziehbar, was gerade auf dem Server passiert. Bei sehr vielen Anfragen an den Server leidet aber die Übersicht.
Bei der Arbeit mit Legacy Anwendungen ist es einem Entwickler selten vergönnt, Ideen für eine neue Software zu finden. Hin und wieder zeigt sich aber ein Problem, das auch in anderen Konstellationen auftreten kann. Bei der Arbeit mit der Template Engine FreshMarker müssen bisher alle notwendigen Daten für die Verarbeitung in einer Map an das Template übergeben werden. Müssen diese Daten aufwendig bereitgestellt werden und werden dann nicht genutzt, ist dies eine Verschwendung teurer Resourcen.
Im ersten Mastodon Beitrag wurden einige Grundlagen zur API erläutert. In diesem Beitrag soll ein eigner Bot erstellt werden. Die Bots auf Mastodon sind spezielle Accounts die autmatisierte Aufgaben erfüllen. Dies können regelmäßige Info-Tröts sein, die Analyse des Nutzerverhaltens, gelegentliche Umfragen oder, oder oder. Ein Mastodon Bot wird wie ein normaler Account erstellt, jedoch wird ein zusätzliches Häkchen gesetzt.
Bei der schnellen Entwicklung von neuen Featuren gerät man irgendwann an den Punkt, dass die Synchronisation der Features Branches mit dem Main-Branch immer schwieriger und die Abhängigkeit zwischen den Feature Branches immer komplexer wird. Eine mögliche Hilfe in dieser Situation sind Feature Flags.