Boehrsi.de - Blog

Am morgigen Dienstagvormittag werde ich die neue Version meines Kommentar-Service ausrollen. Dafür werden meine beiden Services die hier im Blog laufen, also die Suche und die Kommentare, kurzzeitig offline gehen. Der Zeitraum dürfte sich auf wenige Minuten belaufen, da das eigentliche aktualisieren extrem schnell geht.
Der Rollout wird von minimalen Ergänzungen und Anpassungen an Config-Dateien begleitet und alles weitere passiert automatisch. Sobald der automatische Teil erreicht ist, ist die Suche schon wieder online und der Kommentar-Service wird wenige Moment später wieder aktiv sein.
Ich werde dann auf dem Live-System noch ein paar kleine Tests fahren und hoffentlich im laufe des Tages auch das UI Update ausrollen, welches die erweiterte API bedienen kann. Der gesamte Ablauf kann auf meiner Statusseite feingranularer verfolgt werden.

Git ist ein tolles Tool um Code und andere Inhalte zu verwalten, egal ob alleine oder gemeinsam. Ich habe mittlerweile alles was nicht nur ein kleiner Test ist in Git Repositories. Im Rahmen der Nutzung von Git gibt es diverse unterschiedliche Ansätze und Meinungen, wie man Dinge angehen soll und was die jeweilige Best Practice ist.
Im Bereich der Commit Messages habe ich in der letzten Zeit immer mehr Wildwuchs in meinen Projekten bemerkt, obwohl ich eigentlich versucht habe die Dinge überall ähnlich zu benennen. Wichtig ist dies z.B. wenn man später nach Dingen sucht oder z.B. automatisiert Release Notes aus den Commit Messages generieren will.
Durch Zufall bin ich auf die Conventional Commits Spezifikation in einem Flutter Plugin Repository gestoßen und fand den Ansatz sehr passend. Das Ganze basiert auf Ideen des Semantic Versioning open_in_new und der Angular Entwickler Community open_in_new. Die Conventional Commits Spezifikation erweitert die Ideen und Ansätze um feste Richtlinien. Mich persönlich interessiert vor allem der Prefix für Commit Messages, denn eben dieser ist ohne viel Aufwand gesetzt, hilft aber bei den oben genannten Punkten sehr.

• Conventional Commits Spezifikation open_in_new

Vor einiger Zeit gab es eine Feature-Anfrage zu meinem Kommentarsystem, welche ich nun endlich umsetze. Es geht darum Kommentare zu einer News abonnieren zu können. An sich eine simple Funktion, welche aber in ein vorhandenes System integriert werden soll, welches stabil und sicher bleiben sollte, deswegen muss man ein paar mehr Schrauben anziehen.
Da ich aktuell etwas Zeit habe, konnte ich vorgestern die finale Planung und gestern die Implementierung durchführen. In den nächsten Tagen folgt nun weiteres Testing und Debugging. Ich hoffe bis zum Ende der Woche, aber spätestens bis zum Ende der nächsten Woche alle Tests und eventuelle weitere Optimierungen abgeschlossen zu haben, sodass die neue Version online gehen kann.
Die Aktualisierung selbst wird nur wenige Minuten dauern und dürfte die meisten Nutzer nicht betreffen. Alle Informationen zum Service-Update, die kompletten Release Notes und der geplante Update-Termin wird es sobald bekannt in einer separaten News geben.

Heute folgt der letzte Teil meiner kleinen Newssammlung rund um meine Boehrsi.de Statusseite. Denn sobald die eigentliche Seite erstellt ist, geht es ans Hosting und Deployment. Ich habe bekanntlich einen eigenen Server zur Hand, aber Hosting auf diesem macht für eine Statusseite offensichtlich wenig Sinn. Denn wenn der Server, für welchen die Seite den Status anzeigen soll, offline ist, dann wird die Seite natürlich auch offline sein. Ich entschied mich basierend auf meinen Erfahrungen mit GitHub, für eben selbige Plattform fürs Hosting und Deployment. Dort war ich wie bereits erwähnt durchaus glücklich wie umfangreich die Auswahl an vorhandenen Deployment-Workflows ist und auch das Hosting selbst ist sehr unkompliziert.

• GitHub Actions open_in_new
• GitHub Pages open_in_new
• Boehrsi.de-Status GitHub Repository open_in_new

Ich hatte schon häufiger das Thema der Codequalität hier im Blog und habe dafür geworben selbige hochzuhalten. Soll heißen bestehenden Code auch mal zu modernisieren, während der Entwicklung Dinge zu optimieren, statt zu duplizieren und Fehler die man zwischendurch entdeckt direkt zu beheben. Es gibt noch viele, viele weitere Möglichkeiten die Codequalität zu steigern, doch darum soll es heute gar nicht gehen.
Ich wollte mal konkret mitteilen warum ich es für wichtig halte nicht nur links und rechts Dinge anzubauen, sondern eben auch das große Ganze im Blick zu behalten. Ich habe vor kurzem die Ehre gehabt in ein halbwegs umfangreiches Projekt eine neue Funktion einzubauen, welche auf bestehender Logik aufsetzt und diese erweitert. An sich war der Ansatz recht simple, denn es sollte einfach ein bestehender Flow erweitert und mit verschiedenen Kontexten erneut ausgeführt werden. Alle anderen Abläufe, die auf diesem bestehenden Flow aufsetzen, mussten entsprechend angepasst werden, sodass sie den neuen Kontextbezug auch erfassen. Generell wäre das ein Aufgabe für einige Tage gewesen, allerdings wurde alles wesentlich umfangreicher.

Vor wenigen Tagen erschien im Rahmen des Flutter 2.0 bzw. Dart 2.12 Releases der stabile Null Safety Support für Dart. Entsprechend begab ich mich gestern Abend das erste Mal auf den Migrationspfad und aktualisierte meine kleine Anwendung zur Auswertung von Statistiken. Selbige nutze ich produktiv zum erfassen der Nutzerzahlen hier im Blog und auch um die monatlichen Top 10 Listen zu erstellen.
Die Migration ist sehr gut dokumentiert open_in_new und was extrem großartig ist, ist der dart migration Befehl, welcher versucht ein Projekt ohne Null Safety für euch anzupassen. Dabei erhält man einen geführten Prozess, bei welchem ihr die Liste der geplanten Änderungen auf einer interaktiven lokalen Website zu sehen bekommt und dort noch weitere Anpassungen vornehmen könnt. Meiner Meinung nach ist dieses Tool im Kontext der Migration eine glatte Eins mit Sternchen.
Nachdem ausführen der Migration für das kleine Projekt mit ca. 1000 Zeilen reinem Code, blieb tatsächlich nur eine Stelle an der ich manuell Hand anlegen musste. Die App lief anschließend ohne Probleme und weiterer Aufwand war nicht nötig. Hier kommt nun aber eine Empfehlung, die mehr Arbeit bedeutet, selbige meiner Meinung nach aber wert ist.

• Dart Null Safety Migration Guide open_in_new
• Null safety in Flutter open_in_new
• Flutter Website open_in_new

Weiter geht es heute mit meiner kleinen Newssammlung zum Thema Boehrsi.de Statusseite. Heute geht es noch einmal um den reinen Code und wie ich die eigentliche UI erstellt habe. Während die folgenden Beiträge sich eher auf das Setup und Deployment beziehen. Bei Fragen stehe ich wie gewohnt gerne Rede und Antwort in den Kommentaren.
Das Thema Design ist für mich ein spezielles, da ich nicht sonderlich kreativ bin, aber trotz dessen versuche gut aussehende User Interfaces zu erstellen. Ich setze dabei meist auf Minimalismus und den Fokus auf den Content. Generell baue ich fast alles von Grund auf selbst, doch bei diesem Projekt habe ich einen anderen Weg eingeschlagen. Aus verschiedenen Gründen wollte ich weitere Erfahrungen zum Thema Bulma sammeln und entschied mich aus diesem Grund wieder für das CSS Framework.

• Bulma Website open_in_new
• Boehrsi.de-Status GitHub Repository open_in_new

Ich habe in den letzten Monaten häufiger mit Bulma im Kontext der Webentwicklung gearbeitet und das Open-Source-CSS-Framework zusammen mit Hugo, dem Static Site Generator meiner Wahl, genutzt. Resultat ist unter anderem meine Status Website open_in_new. Dieses kleine Projekt hat aber noch ein paar mehr Eigenheiten, denn abseits der eigentlichen Entwicklung nutzte ich bei diesem Projekt das erste Mal umfangreicher GitHub Actions fürs Deployment und GitHub Pages open_in_new fürs Hosting.

• Hugo Website open_in_new
• Boehrsi.de-Status GitHub Repository open_in_new

Libraries machen das Leben von Entwicklern einfacher, denn man muss nicht alles selber schreiben und kann sich auf die eigentlichen Features einer Anwendung konzentrieren. Allerdings gibt man auch Kontrolle und Übersicht ab und entsprechend kann man sich Probleme einhandeln.
Um externe Abhängigkeiten automatisch auf dem neusten Stand zu halten gibt es Dependabot. Früher war Dependabot eine eigenständige Firma, mittlerweile ist man bei GitHub untergekommen, was die dortige Integration natürlich noch einfacher macht. Außerdem ist der Dienst nun komplett kostenlos.
Vor allem auf Sicherheitsupdates weißt Dependabot hin, denn häufig integriert man Abhängigkeiten, aktualisiert selbige aber nicht solange alles läuft. Dabei gehen Sicherheitsprobleme in den Abhängigkeiten natürlich unter. Im Fall eines erkannten Updates wir einfach ein Pull Request erstellt und alles folgt dem gewohnten Flow.
Unterstützt werden unter anderem Ruby, JavaScript, Python, Java (Gradle / Maven), .NET und Docker. Leider ist Dart und somit auch Flutter aktuell noch nicht mit von der Partie und soweit ich es erkennen kann ist derzeit auch nicht geplant das sich dies ändert. Das ist zwar sehr schade, aber durch die pub.dev open_in_new Plattform und das Tooling drum herum, kann man den Prozess der Überprüfung auf Updates hier zumindest teilautomatisiert umsetzen.

• Dependabot Dokumentation open_in_new
• Dependabot Website open_in_new
• GitHub Website open_in_new

Auch wenn ich auf meinem Server ein On-Premise Git Setup habe, welches kleine Aufgaben automatisiert übernimmt, so habe ich mittlerweile immer mehr GitHub Repositories und auch solche wollen automatisiert werden.
Für diese Zweck bietet GitHub mit seinem Actions Setup eine sehr gute und flexible Lösung, welche euch nicht nur viel Arbeit abnehmen kann, sondern auch sehr einfach zu nutzen ist. Aufgrund der Größe der Plattform gibt es bereits jetzt extrem viele Actions, die ihr nur eurem Repository hinzufügen müsst und schon geht es los. Ich nutze GitHub Actions z.B. um für meine Status Seite open_in_new (GitHub Repository open_in_new) automatisiert nach einem Push die Build und Deploy Schritte auszuführen.

• GitHub Actions open_in_new
• GitHub Marketplace open_in_new
• GitHub Website open_in_new