Boehrsi.de - Blog

Derzeit ist Flutter, die Cross-Plattform Lösung für Android und iOS von Google, ein wichtiges Thema für mich. Auf verschiedenen Ebenen arbeite ich aktuell mit Flutter und probiere diverse Dinge aus. Ich bin weiterhin zuversichtlich das diese Cross-Plattform Lösung tatsächlich vielversprechend ist.
Aus diesem Grund werde ich mir am 04. Dezember die Flutter Live 2018 Konferenz ansehen (via Stream) und falls auch ihr Interesse habt, folgt einfach den Related Links. Das Event findet von 14:00 – 20:00 Uhr in London statt und wird bei uns ab 17:00 Uhr Live übertragen, wobei die Keynote um 18 Uhr stattfindet. Ich erhoffe mir dort einiges an neuen Informationen und vielleicht sogar den Release der Flutter Version 1.0. Wie sieht es bei euch aus, interessiert euch das Thema Flutter?

Dass ich ein Fan von Game Jams bin dürfte dem geneigten Leser schon aufgefallen sein, denn häufig schrieb ich über den Ludum Dare oder den Global Game Jam. Umso spannender finde ich dass der Game Off Game Jam von GitHub bis dato immer an mir vorbei ging.
Doch dieses Jahr habe ich ihn nicht übersehen. Selbiges ist auch relativ schwer, denn statt 48 oder 72 Stunden geht der Game Jam einen Monat lang. Der gesamte November darf und soll genutzt werden, um ein Spiel mit dem Theme HYBRID zu entwickeln. Dieses Thema darf völlig frei interpretiert werden und auch die Art und Weise wie und wofür das Spiel implementiert wird liegt beim Entwickler.
Über 3300 Teilnehmer haben sich auf der Plattform itch.io bereits angemeldet und auch ich überlege endlich mal wieder eine Spielidee zu entwickeln und umzusetzen. Falls auch ihr mehr erfahren oder sogar mitmachen wollt, alle weiteren Informationen könnt ihr den Related Links entnehmen.

Seit dem Release meiner aktuellen Blog Version 8.0 habe ich diverse kleine Optimierungen vorgenommen, sodass die Seite von nun an auf die Version 8.1 hören darf. Doch was hat sich denn genau getan? Ich habe alle Bilder innerhalb des Blogs optimiert, CSS + JS + HTML Dateien minified, den Code aufgeräumt, kleinere CSS Optimierungen vorgenommen und alle generellen HTML Fehler behoben. Dadurch sollte die Seite schnell laden, fehlerfrei sein und sehr rund laufen.
Im Rahmen der Fehlerbehebung wurden unter anderem Zoomprobleme unter Chrome auf mobilen Geräten behoben. Verschiedene Fehlerhafte HTML Tags wurden entfernt und Aufrufe für fehlende Ressourcen gelöscht. Zusätzlich wurden Meta-Tags optimiert, was vor allem die Einbindung in sozialen Netzwerken verbessern sollte. Dies sollte sowohl die Darstellung, wie auch die Anzahl der nötigen Request minimieren.
Darüber hinaus gab es kleine Anpassungen an den externen Diensten, welche für die Suche und die Kommentare eingebunden werden. Diese sollten nun noch etwas verlässlicher arbeiten und sind für mich nun via Monitoring kontrollierbar. Alles in allem bedeutet dies einen Score von über 90 bei PageSpeed Insights open_in_new, eine stabile Build Chain + Monitoring für mich und wesentlich mehr Zeit für weitere Projekte mit z.B. Flutter.

Während ich aktuell dabei bin meine zusätzlichen Dienste, die ich in meinem Blog nutze (Suche und Kommentare), zu optimieren, habe ich mir vor einigen Tagen die Zeit genommen und die Seite selbst evaluiert. Sie ist nun seit einigen Monaten online, alles läuft wie gewünscht und ich dachte mir ein wenig finale Pflege könnte nicht schaden.
Allem voran war mein Plan HTML Fehler zu beheben, wofür ich den Nu Html Checker nutzte und nun alle generellen Fehler beheben konnte. Dies gilt für die Hauptseite, sowie für einige Beiträge die ich getestet habe. Es kann natürlich sein das in einigen Beiträgen weiterhin kleine Fehler versteckt sind, allgemein sollte nun aber alles sehr rund laufen.
Weiterhin wollte ich die Ladezeit noch etwas optimieren. Durch eine Reduktion der Seitengröße, welche ich durch die Optimierung der zu ladenden Bilder erreichen wollte, sollte dies geschehen. Bei meiner alten Seite nutzte ich dafür ein Script auf dem Server. Dies macht nun natürlich keinen Sinn mehr, denn die Bilder sollten einfach schon ordentlich im Git Repository landen. Aus diesem Grund schnappte ich mir OptiPNG und jpegoptim für Windows und ließ die Tools ihre Arbeit tun. Die Aufrufe mache ich aktuell noch manuell, ich plane aber sie als post-commit Hooks direkt auf neue Bilder anzuwenden.
Alles in allem konnte ich so Fehler beheben und etwas Geschwindigkeit rausholen. Das meiste dürfte eher Perfektionismus sein, aber auch Kleinvieh macht bekanntlich Mist. Als nächste gibt es wie eingangs erwähnt vor allem Optimierungen bei den externen Diensten, doch dazu später mehr.

Ich entwickle gerne Software, sowohl professionell, wie auch privat, doch manchmal gibt es einfach unschöne Aufgaben, nervige Bugs oder andere Situationen auf die man lieber verzichten würde. Die Top 5 der nervigsten Dinge beim Programmieren - für mich persönlich - möchte ich heute im Rahmen einer weiteren I’m a coder News vorstellen.
Unklare / nicht durchdachte Aufgabenstellung: Egal in welchem Kontext, immer mal wieder stolpert man über nicht fertig gedachte Ideen und Ansätze. Daraus resultiert dann oft eine Änderung der eigentlichen Aufgabe, noch während man initial dabei ist. Dadurch ändern sich auch gerne grundlegende Dinge, sodass ordentlich Hirnschmalz benötigt wird, um entsprechende Anpassungen zu machen ohne komplett neu beginnen zu müssen. Solche Dinge kann man durch ordentliche Planung einschränken, aber leider niemals komplett ausschließen. Gerade im privaten Bereich empfehle ich in diesem Kontext alles zu notieren und ein paar Tage reifen zu lassen, denn wenn man blind drauflos schreibt, landet man häufig in besagter Situation.
Trial and Error Bugfixing: Ein Bug wird entdeckt und die Jagd nach Ursache und Lösung geht los. Auf dem Weg zu Lösung gibt es einige Zwischenschritte und manchmal hat man das Pech einen nicht reproduzierbaren und entsprechend auch nicht wirklich lösbaren Bug zu finden. Dabei kann man dann nur herumprobieren, um sich an eine Lösung anzunähern. Ebenso sieht es aus wenn man zwar genau weiß wo das Problem ist, aber eine klare Lösung nicht erkennbar oder gar möglich ist. Somit kann man auch hier nur via Trial and Error Ansatz versuchen das Problem zu lösen. Am frustriertesten finde ich dabei die Menge an Zeit die man investiert ohne Fortschritte zu machen und ohne Code zu erstellten. Meistens kommt man trotzdem zu einer Lösung und alles ist wieder gut, es gibt allerdings definitiv dankbarere Aufgaben. Wirklich tun kann man gegen diese Art von Problemen leider auch nichts, denn diese Art von Bugs kommt bei der Entwicklung einfach auch vor.

Ein weiterer Beitrag zu meinen Erfahrungen mit dem Static Site Generator Hugo im Rahmen der Entwicklung meines Blogs steht an. Das Thema ist kurz und knapp, aktualisiert Hugo häufig und passt euren Code entsprechend der letzten Änderungen an. Selbiges tat ich gestern, auf die aktuelle Version v0.48 und das Ergebnis ist ein Viertel weniger Build-Zeit und wesentlich sauberer Code an diversen stellen.
Dabei half vor allem das letzte Update, welches es ermöglicht Variablen zu überschreiben open_in_new. Bis dato war dafür die Nutzung von .Scratch Variablen open_in_new nötig, was ich persönlich etwas anstrengend fand. Zusätzlich setze ich umfangreich auf resources.Get, was die Basis für die Minification von CSS und JS Dateien open_in_new ist. Außerdem verwende ich nun .Site.GetPage open_in_new an diversen Stellen. Dadurch kann man schnell und einfach für einen konkreten Pfad die gesamte Seite, inklusive des jeweiligen Kontexts, laden und verwenden. Letzteres half mir z.B. dabei fehlerhafte Links zu beheben, welche durch Slashes in Kategorien oder Tags auftraten.
Die Generierung meiner Seite ist nun zusätzlich mit einem weiteren Parameter versehen. Ich führe den Build-Prozess nun mittels hugo –minify open_in_new aus. Dies sorgt dafür das alle möglichen Ressourcen, wie z.B. HTML Seiten, verkleinert werden. Dies minimiert die Ladezeiten, da die eigentliche Seite kleiner ist. Alles in allem habe ich nun ordentlicheren Code, welcher entsprechend besser wartbar ist und zusätzlich sollte die Seite schneller laden und weniger Fehler beinhalten. All diese Verbesserungen basieren grundlegend auf den Verbesserungen an Hugo bzw. der Programmiersprache Go. Solltet ihr also Hugo nutzen, habt ruhig ein Auge auf die Releases im Github Projekt, welche ihr in den Related Links findet. Selbige sind immer recht umfangreich beschrieben und vermitteln schnell eine Idee, ob das Update für einen selbst hilfreich sein könnte.

Der letzte I’m a coder Beitrag ist schon länger her, was nicht zwangsweise daran liegt das es nicht neues in diesem Bereich bei mir gibt, sondern eher daran das die Beiträge in anderen Sammlungen einsortiert werden. Doch wie ich auch immer, ich habe mal wieder etwas allgemeines, was gut in diese Sammlung passt.
Zuletzt kam ich durch die Droidcon auf das heutige Thema. Es geht um die Aktualisierung von Third-Party-Libraries, welche man in seinen Programmen, Tools oder Apps nutzt. Denn häufig hat man kleine praktische Bibliotheken, die einem Arbeit abnehmen und Funktionen verlässlich und schnell zur Verfügung stellen, ohne dass man das Rad andauernd neu erfinden muss. Ob man dabei alle Nase lang Fremdbibliotheken nutzt oder lieber alles selber schreibt, kommt auf das Projekt und die generelle Einstellung an. Das man bereits eingebundene Libraries aber aktualisieren sollte, sofern man welche nutzt, ist denke ich klar.
Doch warum fällt dies so schwer? Never Change a Running System, denn es funktioniert alles, ist häufig ein guter Grund. Auch häufig ist das fehlende Bewusstsein für diese Bibliotheken, denn wenn alles funktioniert schaut man oft gar nicht mehr nach diesen Inhalten und eventuell verfügbaren Updates. Damit einher gehen dann natürlich diverse Probleme, wie z.B. Abstürze. Unter Android sind häufig Plattformupdates ein guter Grund für ein Update von Libraries, denn oft gibt es nach größeren Systemänderungen Probleme. Doch häufig entdeckt man diese Probleme erst nach längerer Zeit und nach einigen unzufriedenen Nutzern. Reaktiv reagieren ist eben nur eine Notlösung und sollte nicht der permanente Zustand sein.

Vor einiger Zeit wechselte ich von GitList auf Gitea, da ich eine praktische Plattform für meine Git Repositories im Web brauchte. Zum einen wollte ich eine übersichtliche Darstellung für meine privaten Repositories und zum anderen wollte ich von überall schnell auf meinen Code zugreifen können. Diese Dinge erfüllt Gitea sehr gut, doch es kann noch einiges mehr.
Ich habe mittlerweile einige Projekte, manche aktiver und mancher werden eher alle paar Monate mal angefasst. Doch alle haben etwas gemeinsam. Tasks, Features und Bugs wollen verwaltet werden. Dies tat ich bis dato mit TODO-Listen, gespeicherten Tabs im Browser, Zetteln und vielem mehr. Nichts davon war wirklich erfolgreich und vor allem war keine der Lösungen portable und gleichzeitig übersichtlich.
Während eines Urlaubs, wo meine normalen Lösungen nicht wirklich in Frage kamen, schaute ich dann einfach mal wie die Gitea Issue-Verwaltung so aussieht und siehe da, sie ist gut. Eigene Labels, Milestones und TODO-Listen innerhalb von Tasks sind möglich, die UI ist übersichtlich und durch Kommentare kann man Gedanken und ähnliches vermerken. Das Ganze ist sehr ähnlich zu Github aufgebaut, was durchaus gut ist, da viele diese Plattform bereits kennen.

Flutter open_in_new und Dart open_in_new dürften für den einen oder anderen von euch sicherlich keine Unbekannten sein. Im Cross-Platform-Land und vor allem im Android-Bereich ist Flutter aktuell gefragt und auch auf der Droidcon und Google I/O wurde die neue Cross-Platform-Lösung thematisiert.
Ich selbst habe aktuell im Rahmen meiner Arbeit und privaten Entwicklung mit Flutter zu tun und muss sagen ich bin durchaus angetan. Ein erster Blick ließ mich wesentlich positiver zurück als ich es von Cross-Platform-Lösungen gewohnt bin. Denn gegenüber selbigen hege ich eine dezente Skepsis. Doch der Ansatz von Flutter unterscheidet sich von vielen anderen Lösungen, da er nicht auf Webtechniken oder dergleichen setzt, sondern auf einen eigenen losgelösten Renderer. Dies behebt sicherlich nicht alle Probleme, aber kann einige lösen oder zumindest minimieren.
Ich habe in der letzten Zeit diverse Tutorials und Infovideos gesehen und konnte nun auch endlich mal ein paar Zeilen aktiv schreiben. Ich habe unter anderem das Chat-App-Tutorial open_in_new umgesetzt und das Ganze macht tatsächlich Lust auf mehr, auch wenn es natürlich gewöhnungsbedürftig ist. Wie gut oder schlecht sich Flutter im aktiven und längeren Gebrauch schlägt bleibt natürlich abzuwarten, aber ein positiver Einstieg ist ja durchaus auch etwas Erwähnenswertes. Vor allem bei solchen Dingen wie Hot-Reload, einem sehr umfangreichen und reaktiven UI-Framework, einem einfachen Zugang durch bekannte IDEs (Android Studio oder IntelliJ Idea) und einem sehr guten Entwicklungs-Flow.
Wie sieht es bei euch aus, habt ihr schon einmal mit Cross-Platform-Lösungen gearbeitet oder entwickelt und kennt oder nutzt ihr vielleicht auch Flutter?

Vor ca. zwei Jahren veröffentlichte ich Resizy in der Version 0.5. Mein kleines Tool zur Größenveränderung von Bildern kommt vor allem zum Einsatz, wenn man schnell eine größere Anzahl von Bildern verkleinern oder vergrößern will. Zusätzlich gibt es ein paar Komfortfunktion und die Möglichkeit selber an der Entwicklung des Open Source Programms teilzuhaben.
Da ich das Tool recht häufig für den Blog nutze und diese Woche mal wieder auf den Code geschaut habe, dachte ich mir eine Code-Modernisierung sei durchaus angebracht. Diese fiel nun wesentlich umfangreicher aus, da ich doch mehr Dinge angepasst habe als geplant. Aus diesem Grund trägt die nun veröffentlichte Version auch die Versionsnummer 1.0.
Im Funktionsbereich wurde das User Interface aufgeräumt und die Hilfe bei der Nutzung verbessert. Ebenso wurden die Übersetzungen und Fehlermeldungen verbessert. Im Bereich der Menüeinträge ist es nun möglich direkt Feature Requests oder Bug Reports zu erstellen.
Im Code Bereich wurde die gesamte UI neu erstellt und modernisiert, diverse Altlasten wurden entfernt und mehr Java 8 Konstrukte integriert. Die UI ist nun ordentlich von der Logik getrennt und sowohl das Einlesen der Config, wie auch die Nutzung von Übersetzungsdateien wurden gemäß geltenden Standards angepasst. Dadurch ist der Code nun wesentlich aufgeräumter, besser wartbar und fehlerfreier. Weitere Informationen, ebenso wie den Download, findet ihr direkt in den Related Links bzw. auf GitHub.