Boehrsi.de - Blog

Im Rahmen der Software-Entwicklung nutzt man oft Libraries, Tooling und andere Dinge die man selbst nicht komplett durchdringt. Dies ist zu bestimmten Teilen auch in Ordnung und an der Tagesordnung, doch manchmal ist eine Software-Blackbox ein extremes Problem.
Doch definieren wir erst einmal Blackbox. Für mich ist eine Blackbox im Software-Bereich eine Komponente, die man selbst nicht durchdringt und die nicht mit akzeptablem Zeitaufwand, aus welchen Gründen auch immer, verstanden werden kann. Gründe sind hier, auch wenn es sich um Open Source Software handelt, andere Programmiersprachen, zu komplexe Konzepte, fehlende Dokumentation oder ähnliches. Closed Source Software ist natürlich per-se eine Blackbox.

Wann ist eine Blackbox aber nun ein Problem? Meiner Meinung nach wenn sie grundlegende Konzept abstrahiert oder zu essentielle Abläufe übernimmt und dem Entwickler dabei nicht klar ist was wann passiert und warum. Nimmt man z.B. das Build-Tool Gradle open_in_new, so hätte man vielleicht eine Blackbox vor Augen. Diese funktioniert allerdings sehr gut, es gibt eine sehr umfangreiche Dokumentation und auch weitere Ressourcen sind vorhanden. Hier muss man also Vorsicht walten lassen bei Updates und ähnlichem, falls man nicht durchdringt was dies bedeuten könnte. Doch durch vorhandene Dokumentation kann man sich entsprechend und mit akzeptablem Zeitaufwand schlau machen. Insofern würde ich persönlich nicht von einer Blackbox reden, wenn es um Gradle geht.
Hat man nun aber ein derartig wichtiges Tool (z.B. für die Build-Toolchain) oder eine Library die grundlegende Funktionen der eigenen Software übernimmt (z.B. Netzwerk-Interaktionen oder die Implementierung von Protokollen) und eine derartige Informationsquelle ist nicht gegeben, kann man sich in große Probleme manövrieren.

Es ist wieder soweit, nachdem es einige Monate keine Top 10 Liste gab, ist sie nun wieder am Start. Zuletzt gab es diverse Serverprobleme und zusätzlich bin ich leider auch noch vergesslich, sodass diese News häufig ausfiel. Doch sowohl der Server, wie auch mein Gehirn, laufen aktuell rund und entsprechend findet ihr im unteren Teil der News die am meisten gelesenen Beiträge des Monats Mai, absteigend sortiert.

Auch wenn die Umstände dieses Jahr etwas unschön sind und wir alle eher zuhause als unterwegs sein sollten, wünsche ich trotzdem allen Besuchern frohe Ostern. Genießt die hoffentlich ruhige Zeit, telefoniert mit Freunden und Familie und passt auf euch auf.
Etwas Ruhe hier und da kann dem einen oder anderen sicherlich auch mal ganz gut tun, in dieser durchaus schnelllebigen und speziellen Zeit.

Lasst uns doch kurz noch das Framework / die Library aktualisieren. Ein Satz den sicherlich der eine oder andere Softwareentwickler schon häufiger von sich gegeben hat. Vermutlich auch kurz vor einem Release, selbst wenn man eigentlich weiß, dass das vielleicht riskant ist. Aber man testet ja, überprüft nochmal die bekannten Flows und eigentlich sieht ja alles ganz gut aus oder?
Nein, einfach nur nein. Auch wenn es vielleicht von Zeit zu Zeit funktioniert, vor einem Release machen wir sowas einfach nicht. Egal ob es ein Update auf die nächste IDE Version ist, eine aktualisierte Library oder gar eine frische Framework Version, am Ende gibt es immer etwas was man nicht überprüft hat.
Erst heute habe ich diese Lehre wieder gezogen. Denn ich arbeite seit langem mit der aktuellen Beta Version des Flutter Frameworks, um einige Funktionen bereits testen zu können. Nun ergab sich das für ein Projekt, welches eigentlich auf dem Flutter Stable-Branch lebt, eben dieser Beta-Branch ein Problem löst. Da ich schon lange auf selbigem unterwegs bin, entschied ich - wenn auch mit einem mulmigen Gefühl - wir versuchen es mit dem Beta-Branch. Alles in allem habe ich ja schon viel getestet und was soll schon passieren?

Es ist schon wieder etwas her das ich eine News in diesem Bereich geschrieben habe, doch nun wird’s mal wieder Zeit. Denn aktuell grübele ich bezüglich einem Thema, bei welchem ich nicht zu einem optimalen Entschluss komme. Es geht um die Menge der zu verwendenden Guards bzw. Sicherheitsmechanismen, um eine fehlerfreie User Experience zu gewährleisten.
Generell sind wir Softwarenentwickler uns bestimmt einig, dass das User Interface und alles was der Nutzer darin zu sehen bekommt, eher robust sein sollte und entsprechend Fehler gut abfangen muss. Doch wie weit soll man gehen, wenn es darum geht die UI und Logik gegen fehlerhafte APIs zu schützen, die man selber mehr oder weniger unter Kontrolle hat. Ich rede hier von Schnittstellen die auf dem Gerät in Form von Bibliotheken vorhanden sind, nicht von externen APIs, die z.B. auf entfernten Servern liegen (letztere sollten definitiv umfangreich und effektiv abgesichert werdern). Denn auch selbstverwaltete Bibliotheken, welche vielleicht von einem Kollegen der aktuell keine Zeit hat gepflegt werden, können hin und wieder Fehler beinhalten.
Ich bin ein Fan von Fail Fast & Fail Often, denn meiner Meinung nach gehen ansonsten zu viele Fehler unter. Doch wie geht man mit mehr oder weniger bekannten Issues um, welche in darunterliegenden Ebenen vorhanden sind, die teilweise zum eigenen Code gehören.
Baut man Guards ein - vielleicht auch nur temporär - können selbige in Vergessenheit geraten und später das Debugging massiv erschweren. Lässt man die Fehler zu, kann es zu sichtbaren UI Fehlern kommen, was natürlich zu vermeiden ist. Ich persönlich sehe hier eine Zwickmühle, welche ich zwar nicht perfekt, aber für mich für den Moment passend lösen konnte.

Auch wenn es im Kontext Corona wesentlich relevantere Informationen gibt, Boehrsi.de ist und bleibt ein Technik Blog und entsprechend versuche ich in diesem Bereich aktiv zu sein und überlasse die gesundheitsbezogenen Inhalte den Profis.
Doch nun zum eigentlichen Thema dieses Beitrags, der Verschiebung der DroidCon Berlin 2020. Wenig überraschen wird das Event nicht wie geplant im Sommer (01. bis 03. Juli) stattfinden. Stattdessen plant man aktuell die Konferenz im Herbst nachzuholen.
Der konkrete Plan sieht den 07. bis 09. Oktober vor, allerdings ist dieses Datum natürlich nur unter Vorbehalt gesetzt. Aktuell dürften die wenigsten konkret abschätzen können in welche Richtung die aktuelle Situation größere Events verschiebt und wann bzw. ob sie wirklich zeitnah nachgeholt werden können. Solltet ihr aber so wie ich gerne zum Event wollen, haltet euch Anfang Oktober ein paar Tage frei, mit etwas Glück sieht man sich in Berlin.

Es ist zwar schon Mitte März, aber vielleicht interessiert es ja den einen oder anderen was im Februar besonders beliebt war hier im Blog. Die Top 10 Liste der am meisten angeschauten Beiträge findet ihr wie immer im unteren Teil der News. Sortiert wird absteigend nach Anzahl der Aufrufe.
Dieses Mal gibt es wieder eine bunte Mischung aus Gaming- und Coding-Themen, was mich sehr freut, denn beide Themenbereiche liegen mir sehr am Herzen. Falls ihr wünsche zu Themen, Schwerpunkten oder anderen Dingen hier im Blog habt, meldet euch gerne direkt unter dieser News in den Kommentaren.

Corona ist als Thema aktuell in aller Munde und ich hätte nicht gedacht, dass es selbst hier in meinem IT und Gaming Blog zum jetzigen Zeitpunkt relevant wird. Vorweg, keine Sorge, ich bezweifle das ich Corona habe, aber auch mich betrifft die aktuelle Epidemie. Denn eigentlich wäre ich jetzt gerade in den Niederlanden und würde die Appdevcon genießen.
Doch durch die aktuelle Situation wurde das Event auf den September verschoben open_in_new. Meiner Meinung nach die richtige Entscheidung, denn Reisen und Events mit vielen Menschen auf engem Raum, welche mitunter auch aus Risikogebieten kommen, ist eben keine gute Idee.
Das Ganze macht einen definitiv nachdenklich. Denn während man versucht weder zu den ignoranten, noch zu den hysterischen Teilen der Bevölkerung zu gehören, so hat man ja trotzdem eine gewisse Distanz. Spürt man nun die Auswirkungen, wenn auch nur durch abgesagt Events am eigenen Leib, macht es die Situation doch etwas wirklicher und gleichzeitig surrealer.
Ich hoffe das Ganze legt sich eher früher als später wieder und ich hoffe vor allem auf eine gewisse Portion gesunden Menschenverstand. Denn am Ende könnte durch panisches und unüberlegtes Handeln durch den Menschen, die Situation noch um ein vielfaches schlimmer gemacht werden. Und als abschließende Randnotiz, wer auch immer das gesamte Klopapier aufkauft, ich find’s scheiße.

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.

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.