Boehrsi.de - Blog

Ich nutze Git sehr gerne und mittlerweile liegen quasi alle meine Projekte in einem Repository (Remote). Dies betrifft sowohl Code, wie auch textuellen Content und Bilder. Lediglich Daten die im Kontext der Videobearbeitung entstehen sind ausgenommen, da ich sehr große Binaries ungern im Git habe.
Das Ganze läuft so gut, dass ich fast über meine eigenen Flows gestolpert wäre. Damit gemeint ist, dass ich alle Daten im Git ablege und wenn ich etwas lokal lösche oder fälschlicherweise bearbeite stellt dies ja kein Problem dar, denn die Daten sind ja noch im Git und somit habe ich quasi ein implizites Backup.
Genau dieses “alle Daten” ist aber nicht korrekt und hier möchte ich noch einmal etwas die Wahrnehmung schärfen, sowohl von mir selbst, wie auch von euch. Es geht z.B. um Keys, lokale Konfigurationsdateien und jegliche Secrets, welche einfach nicht in einem Git liegen sollten, egal ob privat oder öffentlich. In meinem Fall ging es um Konfigurationsdateien für das Bauen und Signieren meiner Android Apps. Denn zur Zeit bereite ich einen App Release vor, merkte aber gestern ein Release Build ist derzeit nicht möglich. Grund dafür war das Fehlen besagter Dateien. Diese gingen im Rahmen der Neuinstallation meines Systems vor einigen Monaten verloren und wurden beim folgenden Setup nicht wieder hergestellt, denn dort richtete ich lediglich das Git wieder ein.
Es gilt also mal wieder, egal ob man ein Git Repository oder eine andere Versionsverwaltungssoftware nutzt, egal wie man seine Daten verwaltet und egal wie sehr man davon ausgeht das man auf der sicheren Seite ist, Backups bleiben ein muss. Mir haben selbige einiges an Arbeit erspart, denn irgendwelche Passwörter und Keys zurückzusetzen ist etwas worauf ich so gar keine Lust habe, geschweige denn die Zeit. Insofern beleibt mir als Lesson learned nur zu sagen, dass das nutzen eines Git Repositories für mich die Entwicklung und Datenhaltung massiv verbessert, aber eben nicht den Bedarf reduziert regelmäßige Backups zu erstellen.

Wie bereits vor einigen Wochen erwähnt habe ich ein kleines Flutter Package geschrieben, welches es euch erlaubt den Produktnamen / Marketing-Namen eines Android oder iOS Gerät auszulesen. Dabei kann das Gerätemodel, für welches der Name ermittelt werden soll, entweder das aktuell genutzte Gerät sein oder es wird ein bereits bekanntes Gerätemodel eingegeben.
Es gibt zwar schon ein paar Packages / Plugins die in diese Richtung gehen, allerdings benötigen einige eine Internetverbindung oder bringen eine komplette SQLite Library und die entsprechenden Abhängigkeiten mit sich. Dies wollte ich vermeiden, weswegen ich direkt nutzbaren Code für die Lookups generiere. Dafür habe ich Device Identifiers geschrieben, welches bis dato Dart und Kotlin unterstützt. Auf diese Art hat man einen schnellen Lookup der immer funktioniert und keine umfangreichen Abhängigkeiten mitbringt. Die Lookup Daten werden ca. einmal im Monat aktualisiert, sodass das Package vor allem im Android Bereich die aktuellsten Informationen liefern kann. Das Package kann auch für Flutter im Web genutzt werden, hier gibt es allerdings direkt den ermittelten Browser Name weiter, welcher von device_info_plus open_in_new) ausgelesen wurde. Das Auslesen des aktuellen Gerätemodels wird übrigens auch von device_info_plus übernommen.
Das Package ist relativ simpel und der größte Teil der Arbeit ist die Bereitstellung der eigentlichen Daten. Es liegt aktuell in Version 0.3.1, was der fünfte Release ist. Nach dem initialen Release, welcher Android und iOS unterstützte, wurde in den folgenden Versionen der Web Support hinzugefügt. Außerdem gab es kleinere Fehlerbehebungen und Optimierungen, sowie Updates der Lookup Daten.
Solltet ihr Ideen haben wie man das Package noch erweitern oder verbessern kann oder habt ihr Fragen, dann meldet euch einfach in den Kommentaren.

• Device Marketing Names Projektseite open_in_new
• Device Marketing Names auf pub.dev open_in_new
• Device Marketing Names auf GitHub open_in_new
• Device Identifiers Projektseite open_in_new

Ich bin Softwareentwickler und ich nutze Java. Laut Twitter müsste ich mich nun schlecht fühlen, doch überraschenderweise ist dies gar nicht der Fall. Doch warum schreibe ich so etwas überhaupt? Im Rahmen der als Log4shell open_in_new bekannten Sicherheitslücke, in der weit verbreiteten Java Library Apache Log4j 2 open_in_new, gab es natürlich auch diverse verallgemeinerte undifferenzierte Aufrufe Java zu verteufeln. Dabei will ich vorab klarstellen das Java bei weitem nicht das Allheilmittel für die Probleme der Softwarewelt ist, aber eben auch nicht die grundlegende Quelle all dieser.

Im Rahmen meiner Mitarbeit an den Flutter Plus Plugins open_in_new gab es die Anfrage die Produktnamen / Marketing-Namen für Android und iOS Geräte ausgeben zu können. Da dieser Use Case vermutlich eher für eine kleine Anzahl von Entwicklern wichtig ist, wurde entschieden diese Funktionalität nicht direkt in die Plus Plugins zu integrieren.
In diesem Bereich gibt es zwar schon Lösungen, aber einige basieren auf nativen Android / iOS Libraries und einige benötigen eine SQLite Library. Diese Anforderungen gefielen mir nicht, da man am Ende lediglich ein Mapping vom Gerätemodel auf den Produktnamen braucht. Das Model kann relativ einfach ausgelesen werden (z.B. via dem Flutter Plugin device_info_plus open_in_new) und alles weitere kann nicht nur ausschließlich auf der Dart Ebene erledigt werden, sondern das auch mit relativ einfachen Mitteln.
Am Ende braucht man wie oben erwähnt einfach nur eine Map der Daten, welche die Übersetzung von Model zu Name ermöglicht. Dies zu programmieren ist natürlich trivial, auch wenn man auf Dinge wie Lazy Loading achten sollte. Das Problem ist hier einen korrekten und möglichst vollständigen Datensatz zu haben.

• Device Identifiers Projektseite open_in_new
• Device Identifiers auf GitHub open_in_new
• Device Marketing Names auf pub.dev open_in_new
• Device Marketing Names auf GitHub open_in_new

In der Softwareentwicklung und auch als Serverbetreiber ist das Thema Sicherheit natürlich allgegenwärtig. Sicherheitsmaßnahmen wollen eingerichtet und getestet werden. Dafür hat man verschiedene Wege und nachdem die initialen Tests bestanden sind, läuft dann meist alles im alltäglichen Flow weiter.
Zusätzlich zu diesen Abläufen testete ich gestern eher unfreiwillig eine der Sicherheitsmaßnahmen meines Servers. Es geht um Fail2Ban open_in_new, ein Tool welches gegen Brute-Force Angriffe auf Logins und ähnliches schützen soll. Ein kleines feines und unkompliziertes Tool, welches ich gerne als zusätzlichen Sicherheits-Layer betreibe.
Nun hatte ich gestern zwar nicht vor zu prüfen ob Fail2Ban ordentlich läuft, tat es aber trotzdem. In diesem Rahmen war Abends mein Server plötzlich nicht mehr zu erreichen und ich fragte mich wo das Problem liegen könnte. Jegliche Verbindungen meinerseits endeten in Fehlern. Nach ein paar kurzen Nachfragen stellte sich aber heraus, dass nur ich direkt betroffen war, es also gar keinen Ausfall gab. Ein paar weitere Nachforschungen offenbarten dann das Problem. Ein altes Smartphone, welches ich zum Debugging während der Entwicklung genutzt hatte.

Es ist schon etwas länger her das in dieser Sammlung etwas geschrieben wurde, aber nun wird es mal wieder Zeit. Denn nach einem durchaus ausführlichen Gespräch mit einem guten Freund und Entwicklerkollegen, hab ich mal wieder neues Lesematerial für euch.
Heute geht es um das Thema Over-Engineering und das in verschiedenen Formen. Den Anfang macht dabei die oft angepriesene nutzerzentrierte Entwicklung von Anwendungen. Ein schönes Buzzword, welches quasi immer im Raum steht bei Anwendungen die für Endanwender gedacht sind, aber sehr oft und sehr schnell vergessen wird. Egal ob die kleine private Anwendung, ein internes Firmentool oder aber eine große App für einen Kunden, das Problem mit dem Over-Engineering ist allgegenwärtig.
Dies äußert sich quasi immer darin, dass man im stillen Kämmerlein entwickelt und entwickelt. Man baut Features, implementiert Abläufe und davon immer mehr und mehr. Manchmal hat man konkrete User Stories, manchmal hat man sich selber etwas überlegt, aber am Ende basiert alles meist auf Annahmen. Denn selbst die beste Marktanalyse kann nicht garantieren, dass die entwickelten Funktionen der Art und Weise wie der Endanwender mit der Anwendung umgehen wollen entspricht. Dies bekommt man im eingeschränkten Rahmen durch Tests raus, aber am besten einfach durch echte Nutzer, die die Anwendung wirklich im Alltag verwenden. Entsprechend gilt hier Release Early Release Often mehr denn je.

Es gibt wieder neues von mir aus der Flutter Welt. Meine App Tessa hat ein Update erhalten. In dieser Version fügte ich einen Dark Mode und anpassbare Kategorien hinzu. Natürlich wurden auch diverse Fehler behoben und einige Anpassungen an der UI vorgenommen. Letzteres sorgt vor allem für einen modernen Look im Bereich der Snackbars. Ebenfalls verbessert wurde die Performance.
Im Rahmen des Updates habe ich das erste Mal mit Flutter in Verbindung mit einem dedizierten Dark Mode gearbeitet und ich bin durchaus zufrieden. Generell musste ich lediglich mein allgemeines Theme in ein helles und ein dunkles aufteilen und der Großteil war geschafft. Natürlich muss man sich dann noch um eventuelle manuelle Einstellungen kümmern, aber extrem vieles lief einfach so. Selbst UI die von Third Party Libraries gebaut wird, konnte bis auf kleine Ausnahmen ohne Änderungen verwendet werden. Hier merkt man das Flutters Material Komponenten alle aus einem Guss kommen.
Bedenken sollte man allerdings auch die nativen oder statischen Komponenten. In diesem Bereich habe ich vor allem kleinere Anpassungen an den genutzten Bildern vorgenommen und den initialen Splash Screen angepasst. Hierfür habe ich innerhalb von Android selbst die gegebenen Möglichkeiten genutzt. Da zu diesem Zeitpunkt Flutter selbst noch nicht aktiv ist, ist der Splash Screen immer gemäß des System Themes gesetzt und manuelle App Einstellungen greifen dann nachdem der Flutter Kontext geladen ist.

• Tessa - Reit-Assistent bei Google Play open_in_new
• Tessa - Reit-Assistent im Projektebereich open_in_new

Ich habe in den letzten Wochen relativ eingehend erste Schritte mit Jetpack Compose gemacht. Dies ist Androids neues Framework zu Erstellung des User Interfaces. Dabei entfernt man sich weit vom bekannten Ansatz, bei welchem ausgelagertes XML genutzt und später auf die eine oder andere Art mit der eigentlichen Logik verbunden wird.
Mit Compose bewegt man sich in sehr ähnlichen Welten wie bei Flutter. Die gesamte UI wird direkt im Code definiert und entsprechend ist eine extra Verbindungsschicht unnötig. Dadurch spart man sich natürlich einiges an Boilerplate Code. Auf der anderen Seite muss man natürlich umdenken, was mir persönlich durch meinen Flutter Hintergrund relativ leicht fällt.

• Jetpack Compose Website open_in_new
• Jetpack Compose Codelabs open_in_new
• Jetpack Compose Samples open_in_new
• Jetpack Compose Setup open_in_new

Über die Git Struktur meiner Dienste schrieb ich bereits, heute geht es etwas tiefer in die technischen Interna und die Ideen dahinter. Wie erwähnt nutze ich einen Core und selbiger erhält eine beliebige Anzahl an Implementierungen. Dies kombiniert ergibt dann einen Service. Doch wie habe ich dies umgesetzt, wie erfolgt im Code die eigentliche Verbindung zwischen Core und Implementierungen und wie arbeitet man wirklich mit diesem simplen Modularisierungskonzept?
Wie bereits mehrfach erwähnt nutze ich den folgenden Ansatz für kleinere Projekte, an welchen ich meist alleine arbeite. Für mittlere Projekte, mit mehreren Entwicklern, könnte man den Ansatz mit simplem Scripting auch nutzbar machen, für größere Teams würde ich selbigen aber nicht empfehlen. Doch nun zum technischen.

Ich arbeite gerne mit Flutter, migrierte meine internen Java & Android Projekte und schreibe quasi täglich die eine oder andere Zeile Code. Doch ist Flutter auch was für den echten produktiven Einsatz? Diese Frage kann ich seit kurzem nun auch offiziell mit einem klar ja beantworten. Grund dafür ist meine erste Flutter App im Google Play Store (Tessa - Reit-Assistent open_in_new), welche durchaus umfangreich geworden ist und mit Dart und Flutter als Basis sehr gut funktioniert.
Der Kontext ist mit einer Companion App für Pferdebesitzer eher außerhalb meiner Kernkompetenzen, aber genau dies zeigt mir noch mehr das man mit Flutter Apps entwickeln kann, die den eigenen Wünschen oder den Wünschen eines Auftraggebers entsprechen. Grund für das Thema der App ist meine Frau, welche mit dem Reiten ein Hobby gefunden hat, welches durchaus komplex sein kann.

• Tessa - Reit-Assistent bei Google Play open_in_new
• Tessa - Reit-Assistent im Projektebereich open_in_new