Boehrsi.de - Blog

Von Zeit zu Zeit ist es gut über den eigenen Tellerrand hinaus zu blicken und dies sollte auch den Firmen für die man arbeitet klar sein. In der Softwareentwicklung hat man hier mit relativ einfachen Mitteln die Möglichkeit selbiges zu erreichen. So gibt es Konferenzen oder Schulung und auch Workshops zu diversen Themen werden angeboten.
Doch es geht noch viel einfacher und vielleicht sogar besser. Ein kleiner Hackathon, bei welchem gemeinsam im Team neues entdeckt und miteinander entwickelt werden kann. Hierbei lernt man viel, häufig wird selbst ohne Themenvorgaben etwas im Arbeitskontext gebastelt und auch das Teamgefühl wird gestärkt. Die einzige Ausgabe bei einem Hackathon sind die Zeitkosten, denn meistens finden derartige Events im Rahmen der Arbeitszeit statt.
Letzte Woche fand bei mir in der Firma ein derartiger Hackathon statt, welcher sehr positive Ergebnisse hervorbrachte und extrem viel Spaß gemacht hat. Dabei wurden meiner Meinung nach auch durchaus sinnvolle Dinge für die Firmeninteressen umgesetzt, sodass die anfangs erwähnte Win-Win Situation für Arbeitnehmer und Arbeitgeber eingetreten sein dürfte.
Ich freue mich sehr in einer Firma zu arbeiten die Platz für derartige Dinge schafft. Danke @OpenXchange open_in_new an dieser Stelle. Ich hoffe auf viele weitere Events dieser Art, sodass auch ich als Client-App Entwickler hin und wieder in Server-Code oder andere Sachen hineinschauen kann.

• Open-Xchange.com open_in_new

Ich entwickle Java und Kotlin open_in_new Anwendungen in IntelliJ Idea open_in_new und aufgrund meines Android Backgrounds habe ich eine sehr positive Haltung gegenüber Gradle open_in_new als Build-Tool.
Ein Problem über welches ich bei dieser Kombination allerdings immer wieder stolpere, ist das Bauen der finalen Anwendung als JAR Datei. Diese benötige ich logischerweise zur Nutzung der Anwendung, z.B. auf meinem Server.
Bis dato setzte ich hier auf Idea und die dortige Erzeugung der Artifacts open_in_new. Dies funktionierte leider nur unzuverlässig, teils aufwendig und war mit viel Trail and Error verbunden. Vor allem hatte ich bei jedem neuen Projekt die gleichen Probleme und auch mein neues Kotlin Projekt war von selbigen Problemen betroffen.
Ich habe mich heute aus diesem Grund nach Alternativen umgeschaut und bin mit Gradle selbst auf eine extrem gute gestoßen. Denn Gradle bietet mit dem Application Plugin open_in_new eine funktionale und einfache Möglichkeit lauffähige Anwendungen Ready-To-Deploy zu bauen.

In den letzten Tagen habe ich mich mal wieder mit der Erstellung von Webseiten beschäftigt und dort vor allem mit der Gestaltung. In diesem Bereich habe ich in der letzten Zeit wenig getan, denn mein Blog ist aktuell in einem guten Zustand und ich habe mit Flutter und Kotlin verschiedene andere Projekte. Allerdings wollte ich mal ausprobieren mit wieviel HTML und CSS + gegebenenfalls ein wenig JavaScript ich eine ordentliche Grundstruktur und einige wiederverwendbare Komponenten erstellen kann.
Grund dafür ist unter anderem dieser Beitrag meinerseits, in welchem ich mich etwas darüber aufrege das in der heutigen Zeit, welche uns das Flex Layout open_in_new bietet und diverse andere schöne HTML5 + CSS3 Komponenten, alles mit teils extrem umfangreichen UI-Libraries gelöst werden muss. Dies fällt nicht nur in die Kategorie mit Kanonen auf Spatzen schießen, auch die Ladezeit und die Individualität einer Webseite kann dadurch leiden.
Ich will hier nicht gegen Bootstrap open_in_new und ähnliche Libraries wettern. Sie sind meistens extrem gut und bieten für viele Einsatzzwecke genau was man braucht, aber die kleine Firmenseite von Nebenan muss vielleicht nicht unbedingt damit gebaut werden. Hier sollte gelten, dass man nicht immer den einfachsten Weg für den Entwickler nimmt, sondern vielleicht den optimalen allgemeinen Weg. Etwas mehr Aufwand für den Entwickler, dafür mehr Kontrolle, mehr Individualität und auch mehr Flexibilität z.B. bei Kundenwünschen.

Aufgrund der finalen Umstellung meiner Statistikerhebung fiel die Top 10 News für den Dezember 2019 leider aus, was ich hiermit nachhole. Ebenfalls in dieser News enthalten ist die Top 10 Liste für den Monat Januar. Beide Rankings sind im unteren Teil der News zu finden.
Die Listen basieren auf meinen täglichen Logauswertungen und werden von einer kleinen Flutter Web-App aufbereitet. Dabei werden von GoAccess erstellte JSON Dateien eingelesen und teils in textueller und teils in grafischer Form dargestellt. Weiteres dazu gibt es sobald die App ansatzweise funktional und aufgeräumt ist. Soll heißen sobald es kein Prototyp mehr ist, welcher Code-Änderungen benötigt, um andere Monate anzuzeigen.

Ein weiteres Jahr geht zu Ende und entsprechend gibt es wieder Partys, Vorsätze und Feuerwerk. Ich wünsche allen Besuchern einen guten Rusch, viel Spaß auf besagten Partys und ich hoffe euch im nächsten Jahr wieder auf Boehrsi.de begrüßen zu dürfen.

Foto: Von Michael Bieniek via Flickr open_in_new unter CC BY 2.0 open_in_new und weitere Bearbeitung durch Boehrsi.

Es ist so weit, das Weihnachtsfest steht vor der Tür und wir alle sollten dem Internet mal für ein paar Tage weniger Aufmerksamkeit schenken. Zeit mit der Familie sollte im Vordergrund stehen, auch wenn dies in manchen Situationen vielleicht gar nicht so einfach ist. Für ein paar Tage wäre es aber vermutlich trotzdem eine gute Idee Differenzen zu vergessen und einfach nur eine schöne Zeit zu haben.
In diesem Sinne freue ich mich sehr auf die folgenden Tage, welche entsprechend etwas ruhiger hier im Blog werden (danach geht es dann mit knackigen Gewinnspielen und vielen neuen Inhalten weiter) und wünsche alle Besuchern frohe Weihnachten, eine besinnliche und vor allem ruhige und entspannte Zeit. Genießt sie, der Alltag wird uns schnell genug zurück haben.

Es wird mal wieder Zeit für eine I’m a coder News und das heutige Thema werden Reviews sein. Selbige sind extrem wichtig für die Qualität einer Software, welche mitunter maßgeblich durch die eigentliche Codequalität definiert wird. Denn vor allem über längere Zeit ist Software mit guter Codequalität besser wartbar, erweiterbar und erlaubt einen einfacheren Einstieg für neue Entwickler. Reviews sind wichtig, doch auch schwierig und zeitaufwendig. Entsprechend gehen sie manchmal unter, werden nur halbherzig gemacht oder sind zu streng bzw. zu nachsichtig. Hier einen guten Mittelweg zu finden ist schwer, aber extrem wichtig. Nachdem man die eigentlichen Änderungen verstanden und die Funktionalität überprüft hat, folgt der meiner Meinung nach schwerste Teil. Denn nun muss man die Validierung bezüglich der Einhaltung von Coding Guidelines und Naming Vorgaben durchführen.

Der November ist nun schon seit ein paar Tagen vorbei und nun gibt es die dazu passende Top 10 Liste der meistgelesen Beiträge hier im Blog. Die Liste befindet sich wie gewohnt im unteren Teil der News und ist absteigend sortiert. Entsprechend sind die am meisten gelesenen Beiträge oben. Ich filtere nach News die in diesem Jahr erstellt wurden. Sowohl dem seltenen Besucher, wie auch häufigeren Lesern kann ich einen Blick in die Liste empfehlen, denn vielleicht ist das eine oder andere interessante dabei, was man bisher übersehen hatte.

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?

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.