Boehrsi.de - Blog

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).

Vor ca. 14 Tagen schrieb ich ihm Rahmen meiner I’m a Coder Reihe über ein geplantes, kleines Update meiner App FileSize. Selbiges sollte eigentlich bereits letzte Woche erscheinen, aber aus kleineren Anpassungen, Fehlerbehebungen und einem neuen Feature, wurde ein größerer Umbau.
Grund dafür ist Androids Storage Access Framework open_in_new, welches zwar seit Android 4.4 (API Level 19) vorhanden ist, aber nun mit Android 10 Pflicht für den Zugriff auf Ordner und Dateien wird. Da diese Funktionalität der Kern meiner App ist und das Storage Access Framework durchaus neu und ungewohnt für mich ist, dauert die Entwicklung etwas länger.
Denn das Storage Access Framework sorgt nicht nur für Änderungen an internen Abläufen, sondern benötigt auch Anpassungen an der UI und an generellen Abläufen. Außerdem wechsle ich nur für Android Versionen größer gleich 10 auf das Storage Access Framework. Denn neben besseren Sicherheitsstrukturen, ist es leider in der Handhabung, sowohl für den Entwickler, wie auch für den Nutzer und im Bereich der Performance, signifikant problematischer als die normale Java File API. Konkret bedeutet dies mehr Abfragen und Dialoge für den Nutzer und langsamere Scans bei der täglichen Nutzung.
Generell begrüße ich Änderungen, die die Sicherheit verbessern, das Storage Access Framework wirkt allerdings, trotz des fortgeschrittenen Alters, etwas unhandlich und unfertig. Vielleicht liegt dies an meiner mangelnden Erfahrung mit selbigem, ich konnte allerdings diverse Berichte von Entwicklern lesen, denen es zumindest ähnlich geht. Ich hoffe trotzdem die neue Funktionalität im Major Release 4.0 von FileSize bald veröffentlichen zu können.

Das Internet bietet viele Möglichkeiten und vor allem als Softwareentwickler ist es die Basis die eigene Software zu verteilen und eine breitere Masse zu erreichen. Dies ist sehr positiv, aber es gibt auch diverse Schattenseiten in diesem konkreten Bereich, die ich heute einfach mal ansprechen möchte.
Mir geht es vor allem um die Art und Weise wie mit Software und Apps umgegangen wird, wenn mal etwas nicht funktioniert. Dabei sollte man vor allem im Hinterkopf behalten, dass man die meiste Software in diesem Bereich gratis bekommt und genau auf diese möchte ich speziell auch eingehen. Hier bekommen Nutzer also kostenlos Software, die ihnen hilft, sie unterhält oder was auch immer für einen Zweck hat und der jeweilige Nutzer entdeckt ein Problem.

Heute gibt es mal wieder neue Geschichten aus der Welt der Softwareentwicklung. Denn am Wochenende war ich mal wieder fleißig und wollte Googles Bitte nach einem Update meiner Android App FileSize nachkommen. Selbige ist aktuell meine einzige gelistete PlayStore App open_in_new und es wurde mal wieder Zeit die Target-Android-Version anzupassen.
Im Rahmen dieser Aktualisierung dachte ich es wäre eine gute Idee Abhängigkeiten zu aktualisieren, Gradle open_in_new einem Update zu unterziehen und diverse kleinere Aufräumarbeiten durchzuführen. Außerdem wollte ich einen seit langem existierenden Bug beheben und ein neues Feature einbauen. Hier und dort gab es bei diesem Plan natürlich Probleme, doch das eigentliche Problem, welches auch Thema dieses Beitrags ist, ist Vergangenheits-Daniel und im Ernst der nervt mich wirklich.

Der geneigte Java Entwickler wird vermutlich im letzten Jahr nicht nur einmal über Kotlin gestolpert sein. Nicht ohne Grund wird Kotlin aktuell als der quasi Nachfolger von Java gehandelt, denn die moderne neue Sprache bietet diverse Verbesserungen, hält aber größtenteils die Kompatibilität zu Java und den dazugehörigen Libraries.
Im Android-Bereich ist Kotlin bereits die Nummer 1 Empfehlung, wenn es um die App-Entwicklung geht. Speziell für diesen Bereich und um die Sprache allgemein zu lernen, gibt es diverse gute Ressourcen und relativ neu ein komplettes Online-Bootcamp. Dieses beinhaltet diverse Kurse mit aufeinander aufbauenden Inhalten, die euch die Sprache und die Konzepte näher bringen und vor allem die Vorteile im Android-Bereich aufzeigen sollen.
Ich persönlich bin aktuell zeitlich einfach komplett ausgelastet, wodurch es mir schwer fällt außer Dart + Flutter noch etwas Neues zu lernen, plane aber für die nächste ruhigere Zeit den besagten Codelabs einen Besuch abzustatten. Denn ich denke als Android-Entwickler wird Kotlin langsam aber sicher Pflicht und auch in meinen anderen - eigentlich Java vorbehaltenen - Entwicklungsgebieten dürfte Kotlin von Vorteil sein.

• Kotlin Bootcamp Website open_in_new
• Kotlin Website open_in_new

Es ist schon das eine oder andere Jahr her, dass ich über mein kleines Page Speed Insights Bookmarklet schrieb, doch vergessen habe ich es nicht. Heute gibt es ein kleines Update, welches alles einfacher und vor allem wieder funktional macht. Das alte Skript lief nicht mehr, da Google seine Link-Strukturen geändert hat. Die aktualisierte Version sieht wie folgt aus.

• Page Speed Insights Webseite open_in_new
• Page Speed Insights Bookmarklet Projekt auf Boehrsi.de open_in_new

Vor einiger Zeit nahm ich mir die eine oder andere Stunde, um mal in die Programmiersprache Go open_in_new hineinzuschauen. Ergebnis war ein kleiner Web-Service, welcher in meinem Blog als Counter im Hintergrund lief. Der Dienst sammelte dabei keine großen Daten, sondern versuchte zu erfassen wie oft einzelne Unterseiten geöffnet wurden, sowie die gesamte Anzahl der täglichen Besucher zu erfassen. Im Prinzip eine sehr simple Statistik, welche die für mich wichtigen Informationen beinhaltet: Besucher pro Tag und beliebte Artikel für meine Top 10 Beiträge.
Go lieferte dabei eine interessante Basis, da es im Gegensatz zu Java, Kotlin open_in_new und Dart open_in_new teilweise andere Ansätze verfolgt. So war ich in der Lage mit nur sehr wenigen Abhängigkeiten die genannten Funktionen umzusetzen, musste allerdings einiges selber schreiben, was ich bei den genannten anderen Sprachen direkt in Form von vorhandenen Features nutzen konnte. Die initiale Umgewöhnung war zwar nicht einfach, aber ich fühlte mich trotz dessen schnell performant, nachdem die ich die grundlegende leichtgewichtige Idee der Sprache verstanden hatte.

• Go Website open_in_new

Während der Software Entwicklung lernt man viel, teils in Bezug auf neue Programmiersprachen und ähnliches und teils allgemeine Dinge. Zu letzteren zähle ich so etwas wie: “Keine IDE Updates kurz vor einem Release”, nicht “einfach so Libraries aktualisieren” und “das sollte einfach so funktionieren” ist meistens nicht wahr. Die Liste geht noch weiter, quasi unendlich lang, doch worum es mir geht ist diese Lesson Learned auch anzuwenden.
Wir wissen diese Dinge, doch wir vergessen, wir sind im Stress und missachten eigentlich klare Abläufe und dadurch machen wir Fehler. Ich selber habe erst vor kurzem auf meinem privaten System ein Update von IntelliJ Idea 18.1 auf 19.2 gemacht, ohne auch nur eine Sekunde über aktuelle Projekte nachzudenken. Dies wurde natürlich prompt damit quittiert, dass das Projekt nicht mehr baute und ich erstmal das Projekt und die IDE debuggen musste, statt ein neues Feature zu entwickeln.
Um Lessons Learned anwenden zu können muss man sich erst einmal an sie erinnern, somit hilft es im ersten Schritt sie aufzuschreiben. Egal ob in einem Wiki oder auf einem Post-It am Monitor, man sollte den für sich persönlich richtigen Platz finden. Denn hier geht es vor allem um Sichtbarkeit im Alltag. Im nächsten Schritt versuche ich aktuell meine Aufzeichnungen zu bestimmten Kontexten von Zeit zu Zeit erneut zu betrachten, denn was hilft die beste Dokumentation, wenn man sie nicht liest. Um die entsprechenden Dinge dann final anwenden zu können bleibt eigentlich nur der gesunde Menschenverstand. Nicht überstürzt handeln, Backups erstellen, erst prüfen ob z.B. mit Updates Probleme bekannt sind und ähnliches kann helfen Probleme zu vermeiden. Auch Automatisierung in Form von Skripten oder ähnlichem kann hier und da vor Fehlern schützen. Generell fasse ich für mich die Abläufe in Document (z.B. Wiki), Repeat (regelmäßig erneut lesen), Apply (denken und anschließend handeln) und Protect (Skripte, Berechtigungen restriktiv setzen) zusammen.
Mich würden eure Lesson Learned im Bereich der IT interessieren und ich würde mich freuen einige in den Kommentaren finden zu können, denn wir alle lernen nicht aus.

Seit dem Jahresstart entwickle ich aktiv Flutter Apps und meine Erfahrungen und Learnings möchte ich gerne mit euch teilen. Aus diesem Grund starte ich heute meine Newsreihe zum Thema Flutter App Development. Der Fokus liegt dabei vorerst auf dem Smartphone Teil von Flutter, auch wenn die ersten Flutter Desktop open_in_new und Flutter Web open_in_new Vorschauversionen bereits zu haben sind.
Als kleine Einleitung zum Thema ein paar Worte zu Flutter selbst. Flutter ist ein Framework für die Programmiersprache Dart open_in_new. Diese beiden Komponenten bilden die Basis für Googles Cross-Platform Lösung. Flutter ist sehr User Interface zentriert und erlaubt entsprechend diverse Dinge einfach und schnell umzusetzen. Dabei wird eine eigene Rendering-Engine eingesetzt, um alles mit flüssigen 60+ Frames anzeigen zu können. Die nativen UI-Elemente werden dafür vom Flutter Team nachprogrammiert. Die Entwicklung selbst erfolgt mit bekannten IDEs wie Visual Studio Code, Xcode oder Android Studio. Hot Reload macht die Entwicklung dabei extrem schnell. Im unteren Teil der News findet ihr ein kurzes Teaser Video, welches euch diverse relevante Punkte zu Flutter in unter drei Minuten präsentiert.

• Flutter Website open_in_new
• Flutter auf GitHub open_in_new

Microservices sind nicht erst seit gestern ein Trend. In den letzten Jahren entstanden und entstehen mehr und mehr modulare Anwendungen, die eher klein sind und miteinander interagieren und sich ergänzen, anstatt als ein großes monolithisches Programm zu funktionieren.
Doch Microservices sind keine problemlose und wartungsfreie Lösung, denn vor allem wenn man Dinge nicht ordentlich strukturiert und dokumentiert kann es schnell in einem absoluten Chaos enden. Um genau diesen Aufbau der Microservices selbst, den Einsatz und die Wartung kümmert sich das Twelve-Factor App Prinzip.
Die Prinzipien starten mit der Codebase, welche in einem Versionsmanagementsystem liegen soll. Weiter geht es mit Abhängigkeiten, die explizit deklariert und isoliert genutzt werden sollen. An der dritten Stelle steht die Konfiguration, welche durch Umgebungsvariablen definiert werden soll. Ebenso wie der Microservice selbst, sollen Unterstützende Dienste behandelt werden, also als unterstützende und angehängte unabhängige Ressourcen.

• Twelve-Factor Website open_in_new