Boehrsi.de - Blog

In der letzten Zeit Wechsel ich oft zwischen Programmiersprachen, Projekten und Frameworks hin und her. Grund dafür ist unter anderem Flutter open_in_new als neues Framework für professionelle und private Projekte, aber auch Kotlin open_in_new als moderner Ersatz für Java. Nun hat man aber auch aktive Projekte (auch wenn ich mein Projekt FileSize gerade beendet habe) und entsprechend puren Java Code oder Android Projekte mit Java Basis. Bedenkt man nun noch Libraries die z.B. Annotation Processing betreiben, also z.B. Lombok open_in_new oder ObjectBox open_in_new, so gibt es einiges zu beachten.
Daraus ergibt sich häufiges umdenken und öfters auch Fehler, denn gerade wenn man in ein laufendes, aber nicht so aktiv gepflegtes Projekt schaut, welches viele spezielle Dinge benutzt, optimiert man gerne mal Code aus Unwissenheit weg. So passierte es bei mir, dass ich Default-Konstruktoren entfernte, da sie nicht genutzt wurden, ObjectBox diese aber für den generierten Code und die Initialisierung der Objekte in selbigem brauch. Entsprechend werde ich für mich versuchen für nicht implizit klare Dinge wieder mehr auf Kommentare zu setzen. Normalerweise schreibe ich quasi keine Kommentare und sorge dafür dass der Code für sich selbst spricht, doch nutzt man mehrere komplexe Libraries die Boilerplate Code entfernen, kann häufig die Klarheit des Codes leiden.
In einem solchen Fall hat man also einen Vorteil durch weniger Code, aber auch einen Nachteil durch weniger klare Codestrukturen. Kommentare können hier hilfreich sein und ohne viele unnötige Zeilen Code diese Wissenslücke füllen. Mich würde interessieren, wie ihr derartige Dinge löst. Verzichtet ihr generell auf Tools, die zu viel Codestruktur abstrahieren bzw. verbergen oder nutzt ihr andere Ansätze, bzw. schreibt ihr lieber mehr Boilerplate Code, solange selbiger dann besser verständlich ist?

Ich bin ein Fan von Optimierungen und das noch relative neue Bildformat WebP ist definitiv eine Optimierung. Mittels modernem HTML ist eine Umstellung relativ einfach, denn mittels dem picture open_in_new und source open_in_new Tags ist es möglich WebP Bilder und JPGs und PNGs für nicht kompatible Systeme gleichzeitig auszuliefern.
In den letzten Tagen habe ich in mehreren Schritten alle Bilder in meinem Blog auf WebP umgestellt. Ausgenommen sind davon lediglich Bilder die ich innerhalb von Beiträgen eingebunden habe. Der einzige Grund dafür ist meine Zeit, denn hier muss einiges manuell gemacht werden. Die Header Bilder von Beiträgen, Sharing-Icons und weitere Bilder konnte ich relativ einfach durch Anpassung meiner Themes austauschen. Um WebP Bilder anbieten zu können, bin ich in drei Schritten vorgegangen:

Gestern Abend gegen 19 Uhr verabschiedete sich mein Server ins Nirwana. Die Webseiten, Dienste und auch Zugriffsmöglichkeiten via z.B. SSH waren nicht mehr verfügbar. Der Server schien komplett offline oder zumindest vom Netz getrennt, denn auch ein guter alter Ping kam nicht mehr durch.
Nach einem kurzen Telefon mit Strato wurde mir mitgeteilt, dass laut internem Monitoring der Server online ist und ich mit dem Repair-System versuchen sollte mehr herauszufinden. Ich startete kurze Zeit später selbiges Repair-System und konnte meine Festplatten. Um einem eventuellen Datenverlust vorzubeugen, z.B. bei einem Hardwareschaden, startete ich ein Backup, welches über Nacht aktiv war.
Seite ca. 7 Uhr heute Morgen ist der Server nun wieder online. Nach dem erfolgreichen Backup startete ich den Server ohne weitere Änderungen im normalen Bootmodus neu. Aus diesem Grund vermute ich interne Probleme bei Strato führten zum Ausfall, denn auch meine Server Logs gaben keinerlei Fehler oder ähnliches Preis.
Dies war meine erste Auseinandersetzung mit dem Server-Repair-System (minimales Linux, welches via SSH genutzt wird und auf die Hardware Ressourcen des eigentlichen Servers zugreifen kann, um z.B. Festplatten zu mounten), welches mir erlaubt mein System im nicht aktiven Zustand zu verwalten und Notfallmaßnahmen einzuleiten (Fehlerlogs auslesen, Backups erstellen usw.). Das Ganze funktionierte sehr gut und auch die Dokumentation die Strato bereitstellt (z.B. zum Thema Datenzugriff über das Repair-System open_in_new) muss ich an dieser Stelle loben. Ich fand alles relativ schnell und problemlos und konnte alles gewünschte umsetzen.

Bis Ende des Jahres ist es mein Ziel grundlegend produktiv mit Kotlin zu sein. Dabei schaue ich mir Dinge wie Learn Kotlin by Example open_in_new, Tutorials und auch konkrete Kurse an. Bezogen auf die Kurse gibt es dabei etwas Neues von Google. Der Kurs Advanced Android with Kotlin open_in_new ist noch ziemlich neu und zielt wie der Name schon sagt auf eher fortgeschrittene Nutzer ab.
Falls ihr etwas entspannter anfangen wollt ist vielleicht das Kotlin Bootcamp for Programmers open_in_new oder Kotlin for Android Developers open_in_new etwas für euch. Ich werde mir die Kurse auf jeden Fall auch mal ansehen, weiß aktuell aber noch nicht ob ich sie komplett durcharbeiten werde. Denn der Advanced Kurs ist z.B. mit einem Zeitraum von zwei Monaten geplant, was für mich doch etwas langwierig wäre.
Für mich ist es wichtig neue Sprachen, Frameworks und ähnliches mit einem konkreten Ziel zu lernen. Also ein Projekt zu haben, welches ich umsetzen und wirklich nutzen möchte. Wenn es nur lernen des Lernens wegen ist, steigt mein Gehirn meist sehr schnell aus. Deswegen bin ich froh dass ich schon eine Idee für ein kleines Projekt habe, nämlich einen weiteren Micro Service. Mal schauen wie es läuft und ob es bei einem Test-Projekt bleibt oder ob das gute Stück wirklich das Licht der Welt erblicken wird.

Die Android Dev Summit ist seit ca. einem Monat vorbei und wer ähnlich wie ich nicht nach Kalifornien reisen konnte, darf sich zumindest über den Upload aller Sessions des Events freuen. Neben den sicherlich interessanten Keynotes, werde ich mir vor allem alles rund um die neuen Jetpack Komponenten anschauen und versuchen ein paar Kotlin Neuigkeiten zu bekommen.
Vielleicht gibt es ja auch ein paar Worte zum Thema Flutter. Aber selbst wenn nicht, ich denke mindestens die Hälfte der aktuell 73 verfügbaren Videos wird für mich interessant sein. Diese alle anzuschauen wird sicherlich etwas Zeit in Anspruch nehmen, aber ich hoffe spätestens die freien Tage rund um Weihnachten schaffen hier Abhilfe.
Falls auch ihr Interesse an den Videos habt, folgt einfach den Related Links. In selbigen habe ich sowohl die eigentliche Android Dev Summit Website, wie auch die Playlist direkt auf Youtube verlinkt.

In den letzten Wochen habe ich viel in mein altes Projekt FileSize geschaut. Angefangen hat alles mit notwendigen Changes, um weiter mit den Google Play Richtlinien kompatibel zu sein. Weiter ging es mit diversen Bugs die behoben wurden oder sogar ein neues Feature baute ich ein.
Dann kam die Überraschung der verpflichtenden Nutzung des Storage Access Framework open_in_new ab Android 10. Hier steckte ich ebenfalls viel Arbeit hinein. Ich bin in diesem letzten Bereich zu ca. 80 Prozent fertig, allerdings gibt es diverse Probleme, welche ich nicht wirklich zufriedenstellend lösen kann. Zum Ersten ist das SAF leider sehr langsam, sodass ein Scan nach großen Dateien statt wenigen Sekunden, mehrere Minuten dauern kann. Ebenfalls störend ist das initiale Einrichten, welches mittels mehreren Schritten durch den Nutzer geschehen muss. Ich kann dort leider nicht helfen und diverse Otto-Normal-Nutzer werden hier Probleme haben.
Als Programmierer habe ich außerdem das Problem, dass die Basis des Projekts schon älter ist und es entsprechend ohnehin ein paar Ecken und Kanten gibt, füge ich nun aber an diversen Stellen einen Pre- und Post-Android-10 Switch ein, steigert sich die Chance das Dinge kaputt gehen ungemein. Zu guter Letzt bietet z.B. die Files App open_in_new unter Android nun auch einen Bereich zum Aufräumen des Geräts. Neben großen Dateien findet man hier doppelte Dateien, Junk und Daten von nicht verwendeten Apps.
Ich habe mich schlussendlich, trotz der diversen Stunden der letzten Wochen, dazu entschieden FileSize nicht mehr weiterzuentwickeln. Die Nutzerzahlen sanken in den letzten Monaten stark und das zu Recht und die besagte Android 10 Integration ist aktuell nicht wirklich zufriedenstellend machbar. Somit macht es Sinn das Projekt einzustellen, vor allem da ich es nicht in der Qualität entwickeln kann, welche ich mir als Mindestvoraussetzung gesetzt habe. Apps mit ähnlicher Funktionalität gibt es mittlerweile und ich habe dadurch mehr Zeit mich auf meine aktuellen Flutter und Android Projekte zu fokussieren.
Ich werde FileSize im Laufe des Tages aus dem PlayStore entfernen und hoffe bald wieder eine Release würdige App zu haben, denn gar nichts im Store zu haben ist irgendwie etwas schade, vor allem wenn man diverse Projekte zu 90-95 Prozent fertig hat.

Für wiederkehrende Leser dürfte mein Android-Entwickler-Hintergrund mittlerweile bekannt sein, für alle anderen die Information: Ich entwickle unter anderem Android Apps. In diesem Bereich gibt es extrem viele gute Libraries, die einem Aufgaben in allen möglichen Bereichen abnehmen, gut gepflegt sind und extrem viel Zeit sparen.
Die externen Abhängigkeiten sollten dann aber natürlich auch verwaltet, geprüft und aktualisiert werden. Libraries die nicht mehr unterstützt werden, sollten ausgetauscht werden und auch generell sollte man immer ein Auge auf Code haben, welchen man in seine Projekte integriert. Ein gewisser Zeitaufwand ist auf lange Sicht also auch hier zu erwarten.
In diesem Kontext bin ich aber durchaus positiv eingestellt, wenn es um externe Abhängigkeiten geht. Doch mittlerweile wirkt es so, als könnte man vieles zu einfach mit Libraries lösen, denn für teilweise die kleinsten Aufgaben werden komplette Library-Konstrukte integriert und nie wieder mit nur einem Auge betrachtet. Dies gilt für komplexe Dinge, wo Libraries meiner Meinung nach Sinn machen, aber auch für die trivialsten Dinge. Denn eine Abhängigkeit hinzufügen und einfach eine Methode aufzurufen, ist halt immer noch leichter als 5-6 durchdachte Zeilen selbst zu schreiben.
Viele Libraries können hilfreich sein, aber die Selbstverständlichkeit mit welcher, unabhängig von der genutzten Plattform, Programmiersprache oder der Build-Umgebung, Abhängigkeiten überall integriert werden, lässt mich teilweise mit dem Kopf schütteln. Der finale Auslöser dieses Beitrags ist meine Web-Entwicklung mit dem Static-Site-Generator Hugo open_in_new und die damit verbundene Idee warum ich Hugo wählte. Ich arbeite mit Hugo, weil es schnell und einfach funktioniert und dabei eine einzelne ausführbare und aktualisierbare Datei ist. Ohne Abhängigkeiten, ohne 5-Stufigen Build-Prozess, Downloads, Setups, Updates und was man sonst noch alles aufführen könnte.
Ich habe mir ein durchaus komplexes Theme gebaut, kann aber verstehen wenn man bereits fertige nutzen möchte. Was auf meinem Server, für eine andere - nicht von mir entwickelte Website - gerade getan wird. Die Hugo-Webseiten auf dem Server werden mit einem kleinen automatisierten Script, was ich geschrieben habe, gebaut und ich war verwirrt als mir vom Ersteller der Seite mitgeteilt wurde, dass seine Seite nicht erfolgreich erstellt wird.

Aufgrund von einem umfangreichen Update meines Build- und Deploy-Scripts, gab es innerhalb der letzten Tage leider einige kurze Ausfälle des Blogs. Diese sollten nun aber der Vergangenheit angehören, denn das neue Script ist aktiv und läuft soweit ich es beurteilen kann ohne Probleme. Für die nächste Umstellung dieser Art versuche ich auf ein Beta / Staging Environment zu setzen, während ich versuche die letzten Fehler im Script zu beseitigen, sodass Ausfälle komplett vermieden werden können.
Neben der Aktualisierung meiner Build-Infrastruktur, arbeite ich aktuell an verschiedenen Optimierungen innerhalb des Blogs. Hier ist z.B. ein Update für den Such-Service und der Support für WebP Bilder zu erwähnen. Wann diese Änderungen kommen ist aktuell aber noch nicht klar. Sobald es hier konkrete Entwicklungen gibt, werde ich diese in einem gesonderten Beitrag erwähnen.

Ich bin seit langer Zeit häufiger auf GitHub unterwegs open_in_new, entweder für eigene Projekte oder z.B. um Code einer Open Source Library für eines meiner Android Projekte anzusehen. Doch seit diesem Jahr nutze ich GitHub wesentlich intensiver, sowohl privat, wie auch professionell.
In diesem Kontext interessiert mich durchaus was im GitHub Kosmos passiert, wie sich Dinge entwickeln, was Trends sind und was generell einfach interessant ist. Da hilft der The State of the Octoverse Report sehr, denn er bietet eine detaillierte Übersicht zu diversen Themen. Ihr erfahrt hier z.B. das 10 Millionen neue Entwickler im letzten Jahr begonnen GitHub zu nutzen oder das 44 Millionen Repositories erstellt wurden.
Zusätzlich gibt es Informationen zur Nutzung von GitHub im Bereich der Bildung, im professionellen Bereich und wie die globale Verteilung der Plattformnutzer ist. Die Sicherheit auf GitHub ist ebenfalls ein Thema, genau wie beliebtesten Programmiersprachen und welche von ihnen im letzten Jahr am meisten zugelegt oder abgebaut haben. Dart hat hier, vermutlich durch Flutter, übrigens um über 500 Prozent zugelegt. Meiner Meinung nach nicht zu unrecht.
Solltet ihr auf GitHub unterwegs sein oder allgemein Interesse an Open Source und der Entwicklung von Software haben, schaut euch den Report mal an. Er ist auf Englisch und meiner Meinung nach definitiv einen Blick wert.

Während ich aktuell mal wieder in der Android-Welt unterwegs bin (leider noch mit Java, aber mein nächstes Projekt wird Kotlin) fällt mir mal wieder auf wie wichtig es ist bei Plattformen, Frameworks und auch Programmiersprachen am Ball zu bleiben. Seit dem letzten Update meines aktuellen Projekts ist einige Zeit vergangen und es gibt einfach unfassbar viel nachzuholen. Auf der einen Seite ist dies schön, denn ich habe nun neue Möglichkeiten, auf der anderen steigt die Menge an Änderungen langsam in unangenehme Bereiche (Stichwort: Regressions).