Gedanken zur agilen Softwareentwicklung
Wie man es besser macht
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.
Im ersten Teil zum Thema User Directives wurde erläutert, wie diese in die FreshMarker Engine eingefügt sind und wie eigene Java Directives erstellt werden können. In diesem Teil werden die User Directives um FreshMarker Macros erweitert.
Zu den ersten Komponenten der FreshMarker Template-Engine gehörte ein einfaches Plug-In System. Durch diese Komponente wurde die Ergänzung um neue Built-Ins, Formatter und Mapper vereinfacht. Zwei neue Plug-Ins zeigen dabei Stärken und Schwächen des bisherigen Ansatzes.
Nichts ist ärgerlicher bei der Verbesserung von Legacy Software als die Abhängigkeit von Klassen, die sich modernen Sprach Konstrukten verweigern. Eine besondere Gruppe dabei sind all die Klassen, die sich zieren vom Interface AutoClosable zu erben. Diese Klassen sind durch veraltete Abhängigkeiten in das eigene Projekt geflossen und diese Abhängigkeiten sind aus mannigfaltigen Gründen dem Zugriff des Entwicklers entzogen.
Wenn es eine beliebte Sammlung von Bibliotheken für Java Entwickler gibt, dann ist dies wohl Apache Commons. Für jede Art von Problem eines Java Entwickler gibt es dort eine Methode, die eine einfache Lösung verspricht.
Das automatisierte Erstellen von Software hat eine lange Tradition. GNU Make erblickte 1976 das Licht der Welt, Apache Ant im Jahr 2000, Apache Maven 2002 und Gradle 2007. Dies sind nur die bekanntesten Tools zur Build Automatisierung, viele weitere sind bis heute entstanden und es werden wohl noch einige erfunden werden. Alle diese Tools haben ihre Vorzüge und Nachteile und je nach Projekt und Technologie bietet sich eine Tool besonders an. Häufig kommt ein Entwicklungsteam mit den Maven Standard Plugins aus. Hin und wieder gibt es aber den Moment, wo ein zusätzliches Plugin wünschenswert wäre.