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.

Ein praktischer Nebeneffekt meiner neuen Statistiken ist die Rückkehr der Top 10 News. Somit erhaltet ihr nun wieder monatlich einen Überblick zu den beliebten und am meisten gelesenen Beiträgen. Diese findet ihr im unteren Teil der News, sortiert nach Beliebtheit und in absteigender Reihenfolge aufgeführt. Dieses Mal finde ich vor allem interessant wie viele ältere Artikel weiterhin gerne und oft gelesen werden.

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.

Niemand weiß alles und deswegen ist es in der Softwareentwicklung meiner Meinung nach sehr wichtig eine aktive Community zu haben. In einer solchen kann man sich bezüglich der genutzten Sprache, Frameworks und ähnlichen Dingen austauschen. Denn auch wenn es Dokumentationen gibt, die erklären wie man performant eine Sprache nutzt oder wie man in einem Framework konkrete Use-Cases umsetzen kann, so gibt es zu viele unterschiedliche Aufgaben, als das alles dokumentiert sein könnte.
Community-Portale wie Stack Overflow open_in_new, Gitter open_in_new oder auch öffentliche Slack oder RocketChat Channels bieten hier eine Möglichkeit sich asynchron oder synchron auszutauschen und sich gegenseitig zu helfen. Vor allem Stack Overflow dürfte fast jedem Entwickler ein Begriff sein, denn z.B. im Android Bereich findet man quasi alles was man braucht dort.

Obwohl ich aktuell eigentlich viel im Coding Bereich zu sagen hätte, komme ich zurzeit leider nicht wirklich dazu umfangreiche I’m a coder Beiträge zu erstellen. Doch heute nehme ich mir, bei entspannten 32°, einfach mal wieder etwas Zeit.
Thema ist heute die Erstellung von Grafiken und Diagrammen zur Erklärung von Konzepten oder Abläufen innerhalb von Software. Denn wer kenn es nicht, man hat Software entwickelt, verschiedene Konzepte und Ansätze angewendet und dann vergehen einige Monate und vieles gerät in Vergessenheit oder aber ein neues Teammitglied möchte eingearbeitet werden. Bei mir trifft aktuell beides zu, denn bei meinen privaten Projekten vergesse ich durch häufige Kontextwechsel gerne Dinge und auf der Arbeit versuche ich gerade neue Kollegen in mein aktuelles Projekt einzubinden.

Auch wenn heute Sonntag ist und der geneigte Mensch an diesem Tag gerne länger schläft und am besten gar nichts tut, solltet ihr euch heute zumindest einmal bewegen. Denn die Europawahl steht an und in Bremen sogar ebenfalls die Bürgerschaftswahl.
Dabei werde ich hier keine Empfehlungen geben wen man wählen sollte, denn dies ist kein Politikblog, sondern ein IT und Gaming Blog. Wer jedoch in den letzten Wochen Meldungen rund um das Thema Europapolitik mitbekommen hat, sollte zumindest wissen wen man vielleicht nicht wählen sollte.
Doch am Ende ist es ohnehin nur relevant überhaupt wählen zu gehen. Also aufraffen, ein paar Meter Bewegung schaden ja nicht, ein paar Kreuze machen und somit seinen wichtigen Anteil am großen Ganzen leisten. Danach sollte noch genug vom Sonntag übrig bleiben, würde ich sagen.

Vor ca. 14 Tagen endeten die über zwei Wochen andauernden Probleme meines Servers, mit einem Umzug auf ein anderes System. Begonnen hatten die Probleme Ende März mit einem Update auf Ubuntu 18.04. Grund für das Update war der auslaufende Support für das bis dahin genutzte Ubuntu 14.04. Die Neuinstallation und Neueinrichtung verlief generell gut, bis zum Start meiner Java Micro-Services.
Ich konnte lediglich die Suche oder die Kommentarfunktion aktivieren und vermutete zu Beginn Java Probleme. Nach einigen weiteren Test mit nativen Programmen (ein Go Programm, welches lediglich einen simplen String in eine Datei schreibt, wurde genutzt) konnte ich allerdings feststellen, dass die Problematik das gesamte System betraf. Aus einem mir bis heute nicht komplett ersichtlichen Grund war es nicht möglich über eine bestimmte Anzahl von Threads zu kommen.
Diverse Debugging Runden mit und ohne den Strato-Support, das Auslesen aller möglichen Limits, Erhöhen von verfügbaren Ressourcen und Anpassen von Config-Dateien brachte leider keine Besserung. Nach ca. 10-20 gestarteten Threads mit meinem Standard Nutzer oder dem Root Nutzer und einem variierenden globalen Limit von ca. 200 Threads war immer Schluss. Die Hard- und Soft-Limits lagen dabei bei 400 - 800. Im Fall des Erreichens der Threadgrenze war nicht mal mehr das Forken auf der Shell möglich.