Boehrsi.de - Blog

Aktuell gibt es viel Bewegungen in der Flutter Welt. Viele Anbieter von Third-Party-Plugins bringen neue oder stabile Versionen ihrer Tools (z.B. Stream Flutter SDK 1.0.0 Beta open_in_new), aber auch von offizieller Seite gibt es Neuigkeiten. Denn am 03.03.21 findet die Flutter Engage Online Konferenz statt, welche scheinbar sehr interessante Informationen für uns bereithalten soll. Bei Interesse könnt ihr den Related Links folgen und euch für weitere Infos beim Newsletter anmelden.
Abseits von eventuell stabilen Flutter Releases mit Dart Null Safety open_in_new, hoffe ich persönlich auf eine stabile Version der Flutter Integration für den Desktop open_in_new und dort vor allem für Windows. Aktuell arbeite ich an diversen kleinen Tools die auf dem Desktop laufen und Flutter nutzen, entsprechend würde ich mich über einen Release Mode sehr freuen. Doch worum es genau geht und ob die Neuigkeiten kleiner oder vielleicht sogar noch größer ausfallen, werden wir wohl erst im März erfahren. Ich freue mich auf das Event und halte euch auf dem laufenden.

• Flutter Engage Event Seite open_in_new
• Flutter Website 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.

Über Postman habe ich bereits das eine oder andere Mal berichtet und heute möchte ich mein kleines Postman 1x1 mit euch teilen. Ich nutze Postman vor allem bei der Entwicklung von neuen APIs, um selbige schnell und einfach zu testen. Generell plane ich meine APIs und implementiere die ersten Calls, direkt gefolgt von ersten Postman Tests.
Zu Beginn erstellte ich dabei einfach wild Requests und gab Daten immer und immer wieder ein. Mit steigender Request Anzahl und häufiger auszuführenden Tests, wurde dies aber durchaus müßig. Um Arbeit zu erleichtern und das ohne großen Aufwand, erstelle ich diesen Beitrag, denn mit nur sehr wenig Aufwand kann Postman einem das Arbeiten mit APIs massiv vereinfachen.

• Postman open_in_new

Im Rahmen meines Online-Frühjahrsputzes habe ich eines meiner letzten Legacy Java Projekte in Rente geschickt. Mein kleines Tool zum ändern von Namen und Größen von Bildern - Resizy genannt - war eines meiner letzten Java Tools und wurde zuletzt ohnehin wenig aktualisiert.
Ich nutzte das Tool meist um Batch Operationen auf Bildern durchzuführen, welche ich hier im Blog nutzen wollte. In der letzten Zeit brauchte ich das Tool selber sehr selten und auch von extern gab es wenig Interesse. Den Todesstoß für das Projekt gab es nun durch Build-Probleme. Denn aufgrund einer neuen Java Version lässt sich das Projekt nicht mehr ordentlich bauen.
Da ich Java ohnehin aktuell den Rücken kehre (Kotlin und Flutter / Dart ersetzen es) gab es für mich entsprechend nur wenig Motivation eine Trail and Error Problemsuche zu starten. Ob es einen kleinen Nachfolger z.B. in Flutter / Dart geben wird steht aktuell noch nicht fest, aber ausschließen will ich es nicht.

• Resizy - GitHub Pages Seite open_in_new
• Resizy - Boehrsi.de Projektseite open_in_new
• Resizy - Download Link open_in_new

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.

Man lernt nicht aus. Ein Satz den man oft hört und der tatsächlich auch meistens der Wahrheit entspricht. An dieser Stelle möchte ich ein paar Punkte, die ich aus dem letzten Jahr mitgenommen habe, mit euch teilen. Diese betreffen mich dabei meist persönlich und könnten entsprechend nicht auf euch zutreffen, aber ich glaub das eine oder andere ist vielleicht auch allgemein ein häufigeres Problem.
Eine Sache ist für mich das Nein sagen, welches ich gerne zu oft und zu schnell tue. Vor allem wenn von extern Anfragen oder Ideen kommen, egal ob zu konkreten Implementierungen oder aber zu neuen Frameworks, bin ich schnell in einer Abwehrhaltung. Generell bin ich zwar weiterhin der Meinung, dass es besser ist erst Nein zu sagen und später doch noch eine Lösung für ein Problem zu finden, als andersherum, aber hin und wieder sollte man ein paar mehr Gedanken investieren, bevor man vorschnell antwortet. An dieser Schwäche meinerseits versuche ich in 2021 weiter zu arbeiten.

In 2020 habe ich viel programmiert, egal ob privat oder beruflich und nachdem ich mit Java, Dart, Kotlin, JavaScript und Go den einen oder anderen Ausflug in verschiedene Programmiersprachen unternommen habe, möchte ich heute meinen Favoriten mit euch teilen.
Meine Sprache des Jahres 2020 ist Kotlin. Gründe dafür sind neben den modernen und sicheren Konzepten, vor allem die Verständlichkeit der Konzepte. Dabei geht es nicht darum das die Sprache an sich sehr einfach verständlich ist, sondern wie gesagt um die Konzepte und Ideen hinter Entscheidungen. Es gibt wenige Dinge in der Kotlin Welt die ich nicht nachvollziehen kann und Dinge deren Grundlage ich verstehe nutze ich gerne.
Kotlin selbst ist als relativ junge Sprache durchsetzt mit dem Besten aus bewehrten Konzepten, ergänzt durch neue Ideen und Entscheidungen. Letzteres führt zu einer besseren Syntax und sichererem Code. Erstes erlaubt es z.B. mir als Java Entwickler relativ einfach einzusteigen. Dazu gehört auch das man quasi alle vorhandenen Java Libraries im Kotlin Kontext nutzen kann.

• Kotlin Website open_in_new

Während Dart hauptsächlich im Kontext von Flutter Erwähnung hier im Blog findet, gibt es diverse weitere Anwendungsgebiete. Eines von diesen erschließe ich mir gerade und konkret geht es um Dart als Kommandozeilen-Tool.
Generelle setzt man in diesem Bereich ja eher auf die Shell open_in_new unter Linux oder aber PowerShell open_in_new unter Windows. Gerne wird auch Phyton open_in_new genutzt, aber zu Phyton habe ich bis dato keinen Zugang gefunden. Entsprechend fiel meine Wahl auf das für mich naheliegendste.
Dart ist durch Flutter aktuell eine meiner Hauptsprachen, neben Kotlin. Sofern Dart installiert ist und auf dem Pfad hinterlegt wurde, was im Falle eines Flutter Setups vermutlich ohnehin der Fall ist, kann es bereits losgehen. Mit Dart kann man nun im Prinzip fast alles umsetzen was man normalerweise mit anderen Scripting-Lösungen kann, nur halt in einer Sprache die relativ sicher zu programmieren ist und durch Null Safety wird dieser Bereich bald sogar noch ausgebaut. Dart Programme können dann direkt auf der Konsole ausgeführt werden, wie man es z.B. von Phyton kennt. Parameter und ähnliche Dinge können natürlich auch übergeben werden, sodass man hier eine durchaus vollwertige Scripting-Lösung erhält.

• Dart Website open_in_new

Letzten Sonntag erfolgte der erste Live-Test meines neuen Service-Setups und ich konnte den neuen Such-Service direkt online lassen. Als Backup verweilt das alte Setup weiterhin auf dem Server, aber bis dato läuft alles recht problemlos. Ich bin mit dem Ablauf des Deployments trotz eher minimalistischer Planung sehr zufrieden und aus diesem Grund möchte ich meinen Ablaufplan gerne mit euch teilen. Vielleicht hat der eine oder andere ähnliche Deployments geplant und findet hier die eine oder andere interessante Anregung.

Für die Umsetzung bin ich wie folgt vorgegangen:

• Boehrsi.de Status Website open_in_new

Ich lasse mich gerne von neuen Techniken, Programmiersprachen und Frameworks mitreißen, frei nach dem “neu ist immer besser” Prinzip. Doch wie gut ist das eingesetzte wirklich und ab wann kann ich mir eine Meinung darüber erlauben, ob Framework X auch produktiv von mir eingesetzt werden kann?
Genau diese Frage versuche ich mir seit einiger Zeit direkter zu stellen und eventuelle Hypes zu ignorieren. Erst nach der einen oder anderen darüber geschlafenen Nacht versuche ich mir dann ein Bild zu machen. Klappt natürlich nicht immer, manchmal überkommt es einen und manchmal ist ja auch alles Gold was glänzt.
Meistens hat aber auch neue Technik ihre Nachteile, eine Programmiersprache passt vielleicht einfach nicht zum eigenen Einsatzgebiet und hin und wieder ist der eine zusätzliche Gedanke den man sich mit etwas Abstand macht genau der richtige und führt zu einer guten Entscheidung. Denn zumindest ich persönlich habe für mich gemerkt, dass ich auf diese Art vielleicht etwas länger brauche, um die Basis meiner Projekte zu finden, aber dafür ist sie solide und auf Wissen aufgebaut und nicht auf Hype und coolen Animationen.
Damit will ich übrigens nicht sagen, dass man sich nicht mehr für Dinge begeistern darf oder soll, aber es ist halt etwas anderes einen kleinen 2-3 Stunden Test mit etwas Neuem durchzuführen oder ein Projekt über Monate damit aufbauen zu müssen. Insofern versuche ich mir die Freude über gute Software und das sich produktiv fühlen zu erhalten, aber nachgelagert eine Priese differenzierte Gedanken darüber zu streuen.
Wie geht es euch in diesem Bereich, lasst ihr euch vielleicht manchmal auch etwas zu schnell mitreißen, wenn es darum geht den neuen heißen Scheiß zu nutzen?