Boehrsi.de - Blog

In nicht einmal einer Stunde ist es soweit und die diesjährige Google I/O öffnet digital ihre Pforten. Es wird wie gewohnt neues zu Google Software, wie z.B. Android und Flutter, geben, aber vermutlich auch Informationen zu neuer Hardware, z.B. in Form von neuen Pixel Geräten.
Ich bin gespannt welche Änderungen es im Android und Flutter Bereich gibt, denn sowohl als Nutzer, wie auch als Entwickler habe ich mit beiden Bereichen täglich zu tun. Als Nutzer bin ich außerdem auf Informationen zu neuen Pixel Geräten gespannt, denn ich überlege aktuell mein etwas betagtes Handy zu erneuern und Pixel Geräte zu realistischen Preisen wären da auf jeden Fall eine Option.
Im Rahmen der I/O gibt es diverse Aktionen und Aktivitäten, welche ihr auf der offiziellen Webseite findet. Den Link findet ihr in den Related Links. Den Live Stream der Keynote habe ich im unteren Teil der News für euch eingebunden.

• Google I/O Website open_in_new
• Google I/O Youtube Playlist open_in_new

Nachdem ich bereits ein paar Worte darüber verloren habe, warum ich meine Services selbstgeschrieben habe, geht es heute mit den Anforderungen und der generellen Architektur weiter. Als ich vor zwei Jahren meine Java Services schrieb, war das Thema Microservices natürlich auch in meinem Kopf sehr aktiv. Das Resultat damals waren zwei komplett unabhängige Services, für die Suche und die Kommentare. Alles unabhängig, was natürlich seine Vorteile hat, aber eben auch Nachteile.
Die Nachteile wollte ich mit meinen neuen Diensten eliminieren, denn wenn man schon erneut auf der grünen Wiese startet, soll das Ganze natürlich auch ordentliche Verbesserungen bringen. Insgesamt überlegte ich mir die folgenden Anforderungen, welche auf meinen Erfahrungen mit meinen bis dato aktiven Services beruhen.

Ich habe schon oft über die Services, welche die Such- und Kommentarfunktion hier im Blog zur Verfügung stellen, gesprochen. Das ich selbige selbst entwickelt habe wurde auch schon oft breitgetreten, aber auf die Interna bin ich bis dato noch nicht eingegangen.
Dieser Beitrag macht nun den Anfang und ist der Start für eine neue News-Sammlung. Heutiges Thema soll die Frage sein, warum ich die genannten Services selber entwickelt habe und nicht einfach vorhandene Lösungen genutzt habe. Im allgemeinen lässt sich die Frage recht einfach beantworten, denn ich bin ein Softwareentwickler. Entsprechend baue ich meine Software falls selbiges sinnvoll ist, gerne selbst. Doch warum hatte ich in diesem Fall das Gefühl es wäre sinnvoll?

Während es für fast alles ein Plugin / Package gibt im Dart / Flutter Kontext, existieren natürlich trotzdem die kleinen Ausnahmen die einem fehlen. Für diese Dinge schreibt man dann selber Code, verwendet ihn in der nächsten App wieder und entscheidet sich dann vielleicht eine Library daraus zu machen.
Selbiges tat ich vor kurzem und in diesem Zuge habe ich mein erstes Dart / Flutter Package veröffentlicht. OnUpgrade open_in_new soll dem Entwickler helfen eventuell nötige Migrationen bei App-Upgrades durchzuführen oder den Nutzer über neue Funktionen zu informieren. Das Package stellt dabei die Logik zum Speichern, Vergleichen und Auswerten der zuletzt installierten und aktuell genutzten App-Version zur Verfügung. Was im Falle eines Updates ausgeführt wird, wie ein eventueller Dialog aussieht oder wie der generelle weitere Ablauf ist, entscheidet der Entwickler.

• OnUpgrade auf pub.dev open_in_new
• OnUpgrade auf GitHub open_in_new
• OnUpgrade im Projektebereich open_in_new

Über die letzten Wochen hinweg gab es diverse kleine Optimierungen an der Art und Weise wie Inhalte hier im Blog dargestellt und geladen werden. Die Änderungen sind eher minimal bezogen auf das Aussehen, aber die Performance sollte an einigen Stellen besser geworden sein. Vor allem der Cumulative Layout Shift (CLS) open_in_new, also das sich verschieben des Contents, nachdem der eigentliche Inhalt initial geladen wurde, sollte weniger geworden sein. Informationen zu Problemen mit diesen technischen Interna des Blogs erhalte ich übrigens über das PageSpeed Insights Online Tool open_in_new, für welches ich vor einiger Zeit auch ein kleines Bookmarklet erstellt habe.

Eigentlich möchte man defensiv programmieren und entsprechend dem Nutzer möglichst viele Fehler vom Leib halten, das macht auch Sinn. Doch Workarounds und Fallbacks über und über einzusetzen, sodass man irgendwann eher Probleme einbaut als sie zu verhindern, ist meiner Meinung nach schlimmer als ein ordentlich kommunizierter Fehler. Als Beispiel würde ich hier ein Auto nehmen. Es hat Benzin im Tank und falls selbiger bald leer ist fährt man zur Tankstelle. Sollte diese geschlossen sein, macht es Sinn zur Sicherheit einen Kanister mit Benzin auf Reserve zu haben. Was aber eher wenig Sinn macht, ist alle zufällig herumstehenden Kanister des Nachbarn in den Tank zu schütten und zu hoffen es war Benzin dabei. Mit diesem Vorgehen hat man vielleicht in wenigen Fällen Glück, meist ist es aber eher eine wenig zielführende Idee.

Ich mag kleine Scripting Lösungen die mir Arbeit abnehmen und das nicht nur auf meinem Linux Server. Auch unter Windows möchte ich bei der Entwicklung, beim News erstellen und an anderen Stellen, kleine und einfach auszuführende Helfer haben.
Unter Windows gibt es mit der CMD und Powershell gleich zwei Lösungen, welche ich beide ungern nutzen möchte. Nicht weil sie schlecht sind oder dergleichen, sondern einfach weil ich nicht noch eine Sprache / ein Framework zum jetzigen Zeitpunkt lernen möchte. Unter Linux kann ich mit meinem aktuellen Shell Wissen erreichen was ich möchte, doch unter Windows war dies bis vor kurzem wesentlich anstrengender.

• Dart CLI und Server Tutorials open_in_new
• Dart Website open_in_new

Sowohl GitHub Actions, wie auch Flutter waren bereits häufiger Thema hier im Blog und heute geht es um die Kombination aus beiden. Bei einem Großteil meiner GitHub Projekte nutze ich mittlerweile GitHub Actions für diverse Aufgaben und bei meinen Flutter Projekten sieht dies nicht anders aus.
Aktuell nutze ich Flutter Action open_in_new für die eigentlichen Flutter Befehle, Codecov open_in_new für das automatische Hochladen der Tests und abschließend Dart/Flutter Package Analyzer open_in_new, um das Formatting und meinen Pub.dev Score zu überprüfen. Diese Kombination erlaubt es mir mit nur einem Push einen Build zu analysieren, die Tests auszuführen und direkt bei Codecov zu hinterlegen.

• GitHub Actions open_in_new
• Codecov Website open_in_new

Auf eine übersichtliche und schön Art informieren wie der Projektstatus ist, wo man die Downloads findet und welche Lizenz genutzt wird? All das geht und zwar in Form kleiner hübscher Badges. Diese Information ist nicht neu, aber ich habe im Rahmen von einem meiner Projekte nun das erste Mal aktiv mit selbigen gearbeitet.
Für eine kleines Dart / Flutter Package, über welches ich in den kommenden Tagen berichten werde, wollte ich gerne den Status diverser Eigenschaften anzeigen und schaute mich nach verfügbaren Lösungen um.
Badges sind kleine automatisch generierte Bilder, die meist aus einem Label und der dazugehörigen Information bestehen. Normalerweise müsst ihr nur euren Projektnamen, eine öffentliche Id oder eine andere Referenz eintragen und schon geht es los.

• Badges.bar open_in_new
• Shields.io open_in_new

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