Gedanken zur agilen Softwareentwicklung
Im ersten Teil des Beitrags wurde gezeigt, wie man die Klasse InternationalPhoneNumber aus dem Telephone Projekt mit der Jackson Bibliothek verwenden kann. Im zweiten Teil soll die erste Implementierung noch etwas anwendungsfreundlicher werden.
Im letzten Beitrag wurde für die Klasse InternationalTelephoneNumber aus dem Projekt Telephone ein Serialisierer und ein Deserialisierer für Jackson erstellt. Damit ist es möglich diese Klasse direkt in REST Request einzusetzen. Zusätzlich wäre eine Validierung der Telefonnummern wünschenswert. Auf diese Weise könnten Telefonnummern mit speziellen Vorwahlen oder Durchwahlen abgelehnt werden.
Immer wieder kommt es vor, dass man im eigenen Spring Boot REST-Controller Klassen verwenden möchte, die nicht dafür konstruiert wurden. In der Regel trifft dies auf Klassen zu, die aus Dritt-Bibliotheken stammen.
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 letzten Beitrag wurde ein erster Bot für Mastodon erstellt. Der Bot postet mittlerweile drei mal täglich um 8:00, 12:00 und 16:00 Uhr ein englischsprachiges Zitat auf Mastodon. Obwohl die Anwendung schon hinreichend arbeitet, fehlen noch Kleinigkeiten zum dauerhaften Einsatz.
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.
Seitdem die Social Media Plattform Twitter ins Trudeln geraten und ihre Zukunft ungewisser denn je ist, gewinnen alternative Angebote immer mehr an Bedeutung. Bekannteste Alternative zu Twitter ist das dezentrale und quelloffene Mastodon.
Dieser Beitrag zeigt, wie einfach die Mastodon API genutzt werden kann.
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.