Boehrsi.de - Blog

Um sowohl ein hohes Maß an Wiederverwendbarkeit, wie auch ein niedriges Level an Komplexität zu erreichen, habe ich mir für meine Boehrsi.de Services eine Kleinigkeit überlegt. Meinen Ansatz zur flexiblen Entwicklung ohne unnötigen Overhead möchte ich im Folgenden mit euch teilen. Dabei geht es um die Datei- und Git-Struktur, denn auf den Code Aufbau werde ich in einem gesonderten Beitrag eingehen.
Wie bereits erwähnt gibt es viele Wege und das Spektrum ist sehr breit, wenn es darum geht ein Setup für Projekte mit mehreren Modulen, bzw. einem gewissen Level an Flexibilität zu erreichen. Um einordnen zu können wo mein Konzept hilfreich sein könnte und wo es an seine Grenzen stößt, gibt es im folgenden meine Anforderungen und die Beschreibung meines eigentlichen Ziels.

Nachdem ich bereits ein paar Worte darüber verloren habe, warum ich meine Services selbstgeschrieben habe, geht es heute mit den Anforderungen und der generellen Architektur weiter. Als ich vor zwei Jahren meine Java Services schrieb, war das Thema Microservices natürlich auch in meinem Kopf sehr aktiv. Das Resultat damals waren zwei komplett unabhängige Services, für die Suche und die Kommentare. Alles unabhängig, was natürlich seine Vorteile hat, aber eben auch Nachteile.
Die Nachteile wollte ich mit meinen neuen Diensten eliminieren, denn wenn man schon erneut auf der grünen Wiese startet, soll das Ganze natürlich auch ordentliche Verbesserungen bringen. Insgesamt überlegte ich mir die folgenden Anforderungen, welche auf meinen Erfahrungen mit meinen bis dato aktiven Services beruhen.

Ich habe schon oft über die Services, welche die Such- und Kommentarfunktion hier im Blog zur Verfügung stellen, gesprochen. Das ich selbige selbst entwickelt habe wurde auch schon oft breitgetreten, aber auf die Interna bin ich bis dato noch nicht eingegangen.
Dieser Beitrag macht nun den Anfang und ist der Start für eine neue News-Sammlung. Heutiges Thema soll die Frage sein, warum ich die genannten Services selber entwickelt habe und nicht einfach vorhandene Lösungen genutzt habe. Im allgemeinen lässt sich die Frage recht einfach beantworten, denn ich bin ein Softwareentwickler. Entsprechend baue ich meine Software falls selbiges sinnvoll ist, gerne selbst. Doch warum hatte ich in diesem Fall das Gefühl es wäre sinnvoll?

Während es für fast alles ein Plugin / Package gibt im Dart / Flutter Kontext, existieren natürlich trotzdem die kleinen Ausnahmen die einem fehlen. Für diese Dinge schreibt man dann selber Code, verwendet ihn in der nächsten App wieder und entscheidet sich dann vielleicht eine Library daraus zu machen.
Selbiges tat ich vor kurzem und in diesem Zuge habe ich mein erstes Dart / Flutter Package veröffentlicht. OnUpgrade open_in_new soll dem Entwickler helfen eventuell nötige Migrationen bei App-Upgrades durchzuführen oder den Nutzer über neue Funktionen zu informieren. Das Package stellt dabei die Logik zum Speichern, Vergleichen und Auswerten der zuletzt installierten und aktuell genutzten App-Version zur Verfügung. Was im Falle eines Updates ausgeführt wird, wie ein eventueller Dialog aussieht oder wie der generelle weitere Ablauf ist, entscheidet der Entwickler.

• OnUpgrade auf pub.dev open_in_new
• OnUpgrade auf GitHub open_in_new
• OnUpgrade im Projektebereich open_in_new

Eigentlich möchte man defensiv programmieren und entsprechend dem Nutzer möglichst viele Fehler vom Leib halten, das macht auch Sinn. Doch Workarounds und Fallbacks über und über einzusetzen, sodass man irgendwann eher Probleme einbaut als sie zu verhindern, ist meiner Meinung nach schlimmer als ein ordentlich kommunizierter Fehler. Als Beispiel würde ich hier ein Auto nehmen. Es hat Benzin im Tank und falls selbiger bald leer ist fährt man zur Tankstelle. Sollte diese geschlossen sein, macht es Sinn zur Sicherheit einen Kanister mit Benzin auf Reserve zu haben. Was aber eher wenig Sinn macht, ist alle zufällig herumstehenden Kanister des Nachbarn in den Tank zu schütten und zu hoffen es war Benzin dabei. Mit diesem Vorgehen hat man vielleicht in wenigen Fällen Glück, meist ist es aber eher eine wenig zielführende Idee.

Ich hatte schon häufiger das Thema der Codequalität hier im Blog und habe dafür geworben selbige hochzuhalten. Soll heißen bestehenden Code auch mal zu modernisieren, während der Entwicklung Dinge zu optimieren, statt zu duplizieren und Fehler die man zwischendurch entdeckt direkt zu beheben. Es gibt noch viele, viele weitere Möglichkeiten die Codequalität zu steigern, doch darum soll es heute gar nicht gehen.
Ich wollte mal konkret mitteilen warum ich es für wichtig halte nicht nur links und rechts Dinge anzubauen, sondern eben auch das große Ganze im Blick zu behalten. Ich habe vor kurzem die Ehre gehabt in ein halbwegs umfangreiches Projekt eine neue Funktion einzubauen, welche auf bestehender Logik aufsetzt und diese erweitert. An sich war der Ansatz recht simple, denn es sollte einfach ein bestehender Flow erweitert und mit verschiedenen Kontexten erneut ausgeführt werden. Alle anderen Abläufe, die auf diesem bestehenden Flow aufsetzen, mussten entsprechend angepasst werden, sodass sie den neuen Kontextbezug auch erfassen. Generell wäre das ein Aufgabe für einige Tage gewesen, allerdings wurde alles wesentlich umfangreicher.

Es ist wahrlich schlechtes Timing, aber ich habe mir das Jahr 2021 ausgesucht, um mir einen neuen PC zu bauen. Umgeschaut hatte ich mich bereits im Jahr 2020, doch aufgrund der quasi nicht gegebenen Verfügbarkeit von diversen Teilen verschob ich die ganze Aktion. Auch wenn bis dato nur eine minimale Verbesserung der Situation zu sehen ist, hoffe ich in den nächsten Monaten alle Komponenten zusammenzubekommen.
Einige Teile aus meinem alten System werden übernommen, der Kern wird allerdings durch aktuelle Komponenten ersetzt. Dabei ist mir eine hohe Performance wichtig, aber auch ein angemessenes Preis- / Leistungsverhältnis. Außerdem bin ich etwas voreingenommen, was bestimmte Marken und meine Erfahrungen mit selbigen angeht. Entsprechend werde ich mir das folgende System zusammenstellen.

Seit Ende 2019 nutzt mein Blog WebP als Standard Bildformat. Allerdings biete ich parallel noch PNG als Format an, da bis vor kurzem vor allem Apples Safari bzw. macOS nicht in der Lage war WebP Bilder zu verarbeiten. Dies änderte sich mit einem der letzten größeren Updates und entsprechend ist nun der Zeitpunkt gekommen die Dateigröße meines Blogs massiv zu verringern.
Durch diesen dualen Ansatz musste ich logischerweise jedes Bild doppelt auf meinem Server ablegen. Konkret bedeutet dies bei mir ca. 6000, statt 3000 Bilder und ca. 850 MB Platzverbrauch, statt ca. 400 MB.
Die Umstellung sollte für die meisten Nutzer ohne jegliche Änderung vonstatten gehen, denn ein extrem großer Anteil meiner Leser ist bereits seit langem mit Browsern unterwegs die WebP unterstützen. Für die kleine Anzahl an Nutzern mit älteren Safari / macOS Versionen tut es mir wirklich leid. Aber der Overhead, die duplizierten Bilder und die extra zum dynamischen Umschalten genutzten JavaScript Snippets, sind etwas zu viel des Guten im Jahre 2021, wenn es lediglich darum geht Bilder optimiert darzustellen.
Die Umstellung wird im laufe des ersten Quartals 2021 durchgeführt. Sobald alles konkreter wird, wird es eine weitere News geben.

• Can I use - WebP open_in_new

Wie angekündigt wollte ich das letzte Jahr auch im Kontext meines Blogs Revue passieren lassen und dies tue ich hiermit. Denn 2020 war ein spezielles Jahr und auch hier im Blog gab es einige positive und negative Entwicklungen.
Alles in allem läuft der Blog technisch wieder rund. Gerade in der ersten Jahreshälfte war dies allerdings auf Grund von Serverproblemen leider häufiger nicht der Fall. Diverse kleinere Probleme und ein Hardwareproblem im Bereich der HDD sorgten teils auch für mehrtägige Komplettausfälle. Dinge die man natürlich verhindern will und mit ausreichend Aufwand auch könnte, aber am Ende muss das Kosten- / Nutzenverhältnis stimmen.
Abseits der Probleme im Bereich der Stabilität, bin ich weiterhin sehr froh über mein Static Website Setup via Hugo, welches durch die nun neu geschriebenen Kotlin Services ergänzt wird. Die Konvertierung von Java auf Kotlin, inklusive Umbauarbeiten, Aufräumarbeiten und Erweiterungen hat viel Spaß gemacht und die angekündigte Newssammlung zum Thema wird aktuell vorbereitet. Hier wird es für Interessierte also bald mehr geben.
Im Bereich Content konnte ich fast immer mindestens 5 Beiträge pro Woche veröffentlichen, was mein generelles Ziel ist. Entsprechend ist die Quantität durchaus gut, an der Qualität versuche ich aktuell zu arbeiten. Dies bedeutet das Beiträge mehr Tiefe und Inhalt haben sollen. Also z.B. eher ein Tutorial wie man etwas nutzt, statt einem reinen Erfahrungsbericht. Problem dabei ist natürlich der entsprechende Zeitaufwand. Hier versuche ich gerade einen passenden Mittelweg zu finden.

Was macht eigentlich einen guten Entwickler aus? Über viele Punkte kann man hier sicherlich streiten, aber nach diversen Gesprächen mit Kollegen und befreundeten Softwareentwicklern, habe ich den einen oder anderen Punkt zusammengetragen, bei dem wir uns einig waren. Hierbei sollte vorab erwähnt werden, dass diese Liste natürlich nicht vollständig ist.
Beginnen möchte mit der guten alten Annahme, dass weniger Code immer besser ist, was definitiv nicht der Fall ist. Natürlich sollte man unnötigen Code vermeiden, aber manchmal ist es besser ein paar Zeilen extra zu schreiben, die klar machen warum eine Abfrage geschieht, statt unklare Konstrukte einfach so stehen zu lassen. In solchen Fälle erstelle ich lieber eine gut benannte Methode, spare mir Kommentare, halte den Code in einem wartbaren Zustand und füge entsprechend einige Zeilen extra hinzu. So wenig wie möglich, aber so viel wie nötig, um alles verständlich und wartbar zu halten.
Neu ist immer besser und Never change a running system, zwei Sprüche die bestimmt schon jeder Entwickler mal gehört hat. Beide entsprechen zum Teil der Wahrheit, sollten aber immer hinterfragt werden.
Ersterer ist meist der Einstieg, um ein neues Framework oder eine neue Library zu nutzen, was oft spannend ist, aber nicht immer sinnvoll. Hier sollte man wohlüberlegt handeln und sich nicht von coolen Buzzwords blenden lassen. Auch neue Techniken sollten grundlegend zu bestehenden Ansätzen und Konzepten passen und vom gesamten Team getragen werden.
Auf der andere Seite steht das Gegenteil, denn Never change a running system ist gerne die maskierte Aussage “das haben wir schon immer so gemacht, das ändern wir doch jetzt nicht mehr”. Vor allem als Entwickler der lange in einem Bereich mit bestimmten Techniken gearbeitet hat, sollte man trotzdem immer ein offenes Ohr für neue Ideen haben. Denn nur weil man Senior Developer o.ä. ist, heißt dies nicht das ein neuer Junior nicht vielleicht gute Ideen hat. Auch hier gilt abwägen ist wichtig, aber zuhören und offen sein sollte man immer.