Boehrsi.de - Blog

Ich bin täglich auf GitHub unterwegs, da ich dort sowohl privat, wie auch beruflich einiges an Git Repositories liegen habe. Für interne Projekte habe ich zwar zusätzlich Git bei mir auf dem Server laufen + Gitea als Frontend, aber GitHub ist für mich durch meine Arbeit und für Open Source Projekte eine sehr beliebte Wahl.
Da freut es mich und vermutlich auch viele andere sehr, dass GitHub nun auch für Teams kostenlos ist. Bereits vor etwas mehr als einem Jahr wurden private Repositories komplett kostenlos und nun geht es mit einem weiteren Feature weiter. Die aktuelle Änderung zielt vor allem auf die Kollaboration ab, also das gemeinsame Arbeiten an Projekten.
Kostenlos gibt es unendlich viele öffentliche und private Repositories, mit beliebig vielen Mitarbeitern. Dazu sind 2000 GitHub Actions Minuten pro Monat nutzbar und 500MB für eure GitHub Pages. Solltet ihr übrigens mehr brauchen als die angegebenen Werte, auch der Preis für GitHubs kostenpflichtiges Team Paket wurden reduziert (von 9 Dollar pro Nutzer pro Monat auf 4 Dollar).
Für viele dürfte dies sehr attraktiv und ausreichend sein, um gemeinsam an Projekten zu arbeiten. Ich persönlich werde auf jeden Fall überlegen für die nächsten gemeinsamen Projekte dorthin umzuziehen. Denn GitHub bietet ein bekanntes Interface, man hat keinen Verwaltungsaufwand, wie bei Self-Hosted Lösungen und die Plattform bietet einige Features über reines Git hinaus. Was denkt ihr zur aktuellen Entwicklung bei GitHub?

• News zum Thema im GitHub Blog open_in_new
• GitHub Website open_in_new

Aufgrund der aktuellen Situationen werden viele Events abgesagt und auch die IT / Softwareentwickler-Welt ist davon natürlich betroffen. Damit der geneigte Android-Entwickler aber weiterhin sein Wissen aufbessern und sich mit anderen austauschen kann, habe sich die Droidcon Veranstalter etwas überlegt.
Droidcon Online ist eine Event-Reihe, bei welchen ihr zu festen Terminen in den nächsten Monaten einiges neues lernen könnt. Themen wie Jetpack, Multi-Platform Development, Kotlin, Tooling, Security, CI/CD, Testing und Design werden dabei bedient.
Ein jedes Webinar besteht aus zwei 30 Minuten Sessions, einem 15 Minuten Talk und anschließend einer Q&A Runde. Hier könnt ihr euch also Wissen aneignen, euch austauschen, Fragen stellen und mit der Community in Kontakt bleiben. Diese Onlineveranstaltungen sind kostenlos und stattdessen bittet man um eine Spende an den World Health Organization COVID-19 Solidarity Fund, sofern man etwas geben möchte.
Falls ihr übrigens keine Zeit an einem der Termine habt, könnt ihr auch Aufzeichnungen von selbigen anschauen oder z.B. zum zweiten Teil einer Vortragsreihe einsteigen. Weitere Informationen findet ihr in den Related Links. Dort findet ihr die Termine, den FAQ zur Aktion und alle weiteren Informationen. Ich werde auf jeden Fall an einigen Webinaren teilnehmen und bin gespannt was es neues in im Android Land gibt, denn durch Flutter bin ich aktuell ja eher wenig in der nativen Android Welt unterwegs.

• Droidcon Online Website open_in_new
• Droidcon Online - FAQ open_in_new

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.

Als Software-Entwickler kann man in diesen Zeiten nicht nur etwas Hardware für einen guten Zweck zur Verfügung stellen, man kann auch versuchen anderen das Leben etwas leichter zu machen. Denn ein kleines bisschen Entwicklungsarbeit kann hier und dort Dinge für verschiedene Leute einfacher und praktikabler machen.
Ebendies habe ich versucht, indem ich einen kleinen Webservice schrieb. Selbiger erlaubt es dem Verein, in welchem meine bessere Hälfte aktiv ist, zu planen wer das Gelände wann betritt. Dies ist wichtig, um zu verhindern dass eine größere Gruppe von Personen gleichzeitig da ist. Denn wie mittlerweile jedem klar sein sollte, ist dies ein sehr relevanter Schritt, um die Verbreitung von Corona zu verlangsamen.
Der Aufwand war für mich ca. ein Wochenende, inklusive Deployment und ich habe dabei noch einiges gelernt. Denn ich nutzte zufällig das Framework, welches ich ohnehin weiter ausprobieren wollte (Javalin) und Kotlin als Programmiersprache. Somit konnte ich helfen, gleichzeig etwas lernen und am Ende macht es das Leben einiger Nutzer vielleicht ein kleines bisschen weniger kompliziert, in diesen komplizierten Zeiten.
Warum ich das schreibe fragt ihr euch vielleicht, nicht um Lob einzusammeln, sondern eher um zu motivieren. Vielleicht könnt auch ihr, durch welche Fähigkeit auch immer, den Leuten helfen. Oft sind auch Kleinigkeiten eine Hilfe und auch nicht physische Hilfe dürfte für viele relevant sein. Die digitale Welt ist Fluch und Segen zu gleich, lasst uns doch versuchen noch etwas mehr Segen zu verteilen.

Falls ihr gerne neues lernt und im Flutter-Universum unterwegs seid, kann ich euch eine Videoreihe der Flutter-Entwickler ans Herz legen. Die Videos sind wenige Minuten lang und erklären jeweils ein Widget. Widgets open_in_new sind Flutters View-Komponenten, welche ihr nutzt um das User Interface zu bauen.
Dabei gibt es High-Level-Widgets, welche quasi vollwertige Inhalte darstellen, z.B. gemäß dem Material Design Konzept open_in_new oder aber Low-Level-Widgets, welche genutzt werden, um darauf aufbauend eigene Strukturen zu erstellen.
Die Flutter Widget of the Week Youtube-Reihe open_in_new bietet Einblicke in beide Ebenen. Dies geschieht wie erwähnt kurz und knapp, aber sehr hilfreich erklärt. Alleine das Wissen das bestimmte Widgets existieren ist manchmal Gold wert. In der Video-Reihe gibt es alles vom Expanded open_in_new Widget, bis hin zum StreamBuilder open_in_new und auch komplexe Dinge wie ClipRRect open_in_new oder DraggableScrollableSheet open_in_new werden gezeigt.
Ich habe hier zuletzt das generische Builder open_in_new Widget kennen gelernt, welches im Prinzip nur eine weitere Ebene in Bezug auf den BuildContext etabliert. Klingt nach unnötiger Schachtelung, aber gerade im Zusammenhang mit dem Provider Package open_in_new oder InheritedWidgets open_in_new generell ist dies extrem praktisch und erspart die Erstellung unnötiger neuer Widget-Strukturen.
Mittlerweile gibt es fast 75 Videos in der Playlist, welche einen schönen Überblick über verfügbare Widgets und generelle Ansätze des Frameworks liefert. Meiner Meinung nach auf jeden Fall einen Blick wert.

• Flutter Widget of the Week Youtube-Reihe open_in_new
• Flutter Website open_in_new

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.

Flutter ist aktuell sehr präsent bei mir, wenn es um die Entwicklung von Software geht. Aus diesem Grund habe ich mir nun auch die Flutter Web Integration angeschaut, welche aktuell auf dem Flutter Beta Channel verfügbar ist.
Nebenbei sei übrigens erwähnt, dass dies mein letztes Projekt war, welches meiner Flutter App Development Newsreihe im Wege steht. Doch nun zu meinen Erfahrungen mit dem Flutter Web Support. Generell funktionieren die meisten Dinge der bekannten App-Entwicklung auch im Web-Kontext, allerdings sollte man vor allem bei Third-Party-Libraries open_in_new darauf achten das Web-Support gegeben ist. Doch selbst dann sollte man lieber noch einmal konkret testen.

• Flutter Web open_in_new
• Flutter Website open_in_new