Boehrsi.de - Blog

Die letzte I’m a coder News fiel aufgrund meines Urlaubs aus und genau dieser soll auch dieses Mal Thema meiner News sein. Denn Urlaub ist zwar eigentlich eine Zeit in der man nichts schafft, aber genau dies kann auch helfen. Dabei rede ich von richtigem Urlaub, außerhalb des eigenen Heims und somit auch außerhalb der Reichweite der eigenen privaten Projekte. Denn eine Pause in diesem Bereich kann Motivation und neue Ideen bringen. Bei mir hat beides tatsächlich funktioniert, denn nach dieser einwöchigen Pause habe ich nun einiges an neuen Ideen für verschiedene Projekte und zusätzlich habe ich wieder richtig Lust mal etwas in die Tasten zu hauen. Außerdem hat man durch einen Urlaub natürlich auch allgemein wieder neue Energie, zumindest wenn alles wie geplant lief. Somit kann ich nur sagen, auch ein Urlaub von den privaten Projekten kann helfen wieder besser voranzukommen. Um die ausgefallene I’m a coder News aufzuholen gibt es morgen direkt eine weitere für diese Woche, denn diese hier war entsprechend für die Woche davor.

Warum bin ich eigentlich Programmierer oder warum wollte ich es werden? Dies ist das heutige Thema meiner I’m a Coder News. Irgendwie war für mich schon sehr früh klar das ich etwas im Bereich Informatik machen möchte. Ich interessierte mich schnell für Software und auch für Hardware. Während meiner Schulzeit nutzte ich IT bezogene Fächer und mein Informatikstudium brachte mich dann noch weiter auf den Weg in Richtung Softwareentwickler. Während meines Studiums arbeitete ich parallel als IT-Support, wo ich zu einem großen Teil Hardware bezogene Aufgaben übernahm und etwas programmierte. Dabei stellte ich fest das Hardware zwar interessant ist und ich gerne alle paar Jahre einen neuen Gaming-Rechner aufbaue und alle übrigen Teile in Systemen meiner Familie verbaue, ich es aber ungern auf Dauer täglich machen würde. Vor allem die Abwechslung und die nötige Herausforderung beim Erkennen und Lösen von Problemen fehlte mir, denn meistens tauschte ich lediglich Komponenten. Genau dieses Erkennen von Problemen und verschiedene Lösungswege zu erarbeiten ist nämlich meine Hauptmotivation bei der Entwicklung von Software. Ich oder jemand anders hat eine Aufgabe und um diese zu lösen müssen eine Reihe von Teilproblemen erkannt und entsprechend verteilt und gelöst werden. Genau dieses herangehen, welches auch bei sehr ähnlichen Problemen unterschiedlich sein kann und natürlich auch die schlussendliche Lösung sind für mich die Motivation hinter dem Programmieren.

Heutiges Thema meiner Coder News sind neue coole Techniken, wie z.B. Cloud Dienste, neue APIs und grundsätzlich alles was man mal ausprobieren möchte, aber dann auf Limitierungen stößt die einen zum eventuellen Umdenken zwingen. Denn aktuell bin ich in der Situation eine kleine App zu basteln und für diese habe ich mich entschieden auf Firebase open_in_new zu setzen. Firebase ist Googles relativ neue Plattform für diverse Funktionen, darunter auch eine Realtime-Database welche ich für mein Projekt nutze. Dort werden Daten nicht relational, sondern als großes JSON Konstrukt abgelegt und verwaltet. Dies fordert einen zum Umdenken auf, wenn man vorher aus dem SQL Bereich kam. Soweit so gut, alles läuft nach einigen Anläufen und es geht wirklich gut von der Hand. Doch dann kommt man an Punkte an denen die neue Technik sich anders verhält als man es sich wünscht und Dinge schlicht nicht möglich sind. Dazu gehört bei mir der Wunsch nach einem Query, welches ähnlich dem LIKE %SEARCH_STRING% SQL Statement ist. Dies ist schlicht nicht möglich bzw. vorhanden. Dadurch habe ich nun eine neue Technik, die ich eigentlich nur ausprobieren will weil sie neu und interessant ist, auf der anderen Seite aber eigentlich nicht exakt das ist was ich brauche. Somit stelle ich mir quasi selbst ein Bein, denn ich möchte die Basis nun nicht mehr ändern. Ich vermute ich werde Mittel und Wege finden alles entsprechend zu implementieren, doch im Prinzip verfehle ich dadurch mitunter Einsatzgebiete der jeweiligen Tools oder Plattformen. Neues zu nutzen ist also gut zum Lernen, doch man verbeißt sich leider auch leicht. Zumindest mir geht es so, wie sieht es da bei euch aus? Schafft ihr den Absprung in solchen Situationen oder zieht ihr das Ganze dann auch eher durch? Für mich ist der Hauptgrund weiterzumachen übrigens das ich weiter lernen möchte mit Firebase umzugehen, denn die Plattform ist extrem mächtig und wird mir sicherlich noch einmal gute Dienste in Projekten leisten, wofür ich sie aber erst einmal wirklich durchdringen muss.

Abwechslungsreiche Aufgaben sind heute das Thema, denn auch in der Softwareentwicklung gibt es nicht nur immer wieder dieselben Dinge. In diesem Kontext meine ich nicht den Unterschied zwischen Bug und Feature, sondern eher in welchem Bereich man gerade innerhalb der Anwendung unterwegs ist. Ich denke hier an Bereiche wie Netzwerk, User Interface, Business Logic, Abstraktions-Layer, Performance Optimierung und so weiter. Denn zum einen wird durch einen häufigen Wechsel die Vielfalt der Fähigkeiten der Entwickler verbessert und zum anderen lernt man die gesamte Anwendung kennen, wenn man gemeinsam Dinge implementiert. So entsteht weniger Inselwissen und falls einer der Entwickler mal ausfällt kann einer anderer besser einspringen. Vor allem im professionellen Bereich ist dies sehr wichtig. Deswegen begrüße ich es, dass in meinem Arbeitsleben aktuell darauf geachtet wird das zum einen das Wissen verteilt wird und zum anderen auch das quasi alle Entwickler gemeinsam über die Aufgabenverteilung nachdenken bzw. ein gewisses Mitspracherecht haben und der Lead nicht alles ohne weitere Rückfragen blind vergibt.

Heute mal wieder eine Kleinigkeit aus meiner Coding Welt, das Thema ist Produktivität und wann man sich wirklich produktiv fühlt. Denn häufig hat man Aufgaben die sich in ihrer Größe stark unterscheiden. Vor allem im professionellen Bereich tritt dies häufig auf. Denn manchmal hat man viele Bugs, die man teilweise schnell nacheinander beheben kann und sich dementsprechend produktiv fühlt, doch dies ist dann eher kurz der Fall. Denn auch wenn man vielleicht viel in Sachen Tickets erreicht hat, so ist der allgemeine Einfluss der Arbeit eher minimal. Da ist es dann eher relevant eine oder zwei Wochen an einer großen Aufgabe zu arbeiten und am Ende ein neues Feature zu implementieren oder ein neues Konstrukt für die Basis der Anwendung. Hier hat man dann aber wiederum das Risiko nicht in der gesetzten Zeit fertig zu werden und am Ende gar nichts im festgelegten Zeitraum geschafft zu haben. Hier ist es also wichtig, dass man wie bereits von mir angesprochen, die Arbeitspakete ordentlich und lösbar einteilt. Grundsätzlich ist es aber nach meiner Erfahrung auf jeden Fall gut und wichtig Abwechslung zu haben. Also größere Aufgaben die sich mit kleineren abwechseln. Das sorgt für einen ausgeglichenen Alltag und wenig Frustration.

Heute ist mal wieder Sonntag und somit wird es Zeit für eine I’m a coder News. Dieses Mal soll es ein wenig um die richtige Aufteilung von Arbeitspaketen gehen. Wie auch schon in den letzten Beiträgen können die folgenden Dinge meiner Meinung nach sowohl bei privaten Projekten, wie auch im professionellen Bereich eingesetzt werden. Denn eigentlich ist die Regel hier recht einfach: „Lieber viele kleine Schritte nacheinander, als einen Großen“. Dies bietet mehr Möglichkeiten Fehler zu entdecken und zu korrigieren und der Fortschritt kann besser verfolgt werden. Die Zerteilung von Arbeitspaketen ist übrigens nicht nur während der Planungsphase wichtig, auch während der Implementierung können neue Komponenten entdeckt werden, die für ein bestimmtes Ticket relevant sind. Diese können dann innerhalb des eigentlichen Tickets implementiert werden oder aber man gliedert sie aus und bearbeitet diesen Teil zuerst und packt das eigentliche Ticket dann oben drauf. Das bietet einfacherer Reviews und man ist flexibler, wenn z.B. andere Personen von den kleineren Teilen des Tickets bereits profitieren können. Ein wenig mehr Aufwand in Form von Tickets erstellen oder Git Commits entsteht vielleicht, ist aber meiner Meinung nach zu verschmerzen. Wie geht ihr in diesem Bereich vor und vor allem warum tut ihr dies entsprechend?

Ich schreibe, wie schon mehrfach erwähnt, aktuell an einem Web-Service, dieser kann von angemeldeten Nutzern genutzt werden und bietet eine API für alle interessierten Clients. Dabei habe ich für mich festgestellt wie hoch die initialen Hürden sind und wie gut es nach dem ersten Einstieg voran geht. Denn obwohl ich nebenbei schon recht lange daran arbeite, sind noch nicht viele Endpoints gegeben und damit auch nicht viel Funktionalität. Doch nachdem nun die Authentication und Authorization fertig ist läuft es quasi wie von selbst. Neue Endpoints sind aufgrund der gegebenen Grundstruktur nun einfach umzusetzen, die Methoden und Klassen für einen schnellen Zugriff sind bereits vorhanden und allgemein ist nun ein Flow vorhanden der ein schnelles und effektives Arbeiten erlaubt. Schreiben tue ich dies um euch falls ihr am Anfang eines solchen Projekts steht Hoffnung zu geben, denn der Anfang kann wirklich etwas frustrierend sein. Dazu sei auch noch gesagt, dass es mittlerweile viele Tools und Dienste gibt, welche euch gerade im Bereich der Authentication und Authorization vieles abnehmen. Einziger Nachteil für einige ist, dass ihr euch dann auf andere Anbieter für Logins verlasst, doch sofern ihr nichts gegeben Google und Konsorten habt ist dies nicht zwangsläufig ein Problem. Alles in allem kann ich nur sagen, dass ein solides Framework als Basis, eine große Anzahl an Tutorials und eine aktive Community bei Startproblemen helfen und sofern man den ersten Einstieg geschafft hat es durchaus gut voran gehen kann. Zur besseren Einordnung abschließend noch der Hinweis ich schreibe eine REST ähnliche Spring Boot Anwendung.

Es ist Sonntag, die Woche neigt sich dem Ende entgegen und ich habe das Gefühl noch etwas schreiben zu müssen. Diese Woche möchte ich ein paar Worte zu Dokumentationen verlieren, denn diese werden zu häufig vernachlässigt. Egal ob im privaten oder professionellen Kontext, Dokumentation sollte erstellt werden. Dabei ist die Form meiner Meinung nach nur zweitrangig wichtig, solange man irgendwo die nötigen Informationen findet. Denn auch wenn Code möglichst selbsterklärend sein sollte, so kommt es oft genug vor das man das große ganze nicht basierend auf einem einzigen Code Fragment erkennen kann. Backtracking ist dann eine Möglichkeit, aber diese ist zeitaufwendig und nicht immer zielführend. Ein paar einfache Worte am Anfang einer Klasse, ein Wiki mit ein paar Sätzen oder sogar eine kleine Grafik und schon fällt einem das Verstehen wesentlich leichter. Dies gilt übrigens auch für eigenen Code, denn es ist interessant wie schnell man vergisst was man zwei Tage zuvor entwickelt hat und was man sich dabei gedacht hat. Außerdem fällt einem manchmal beim dokumentieren auf, dass Dinge anders mehr Sinn gemacht hätten und man dementsprechend noch optimieren kann. Ich selber bevorzuge Wikis und möglichst wenig In-Code Dokumentation. Auch Grafiken stehen bei mir sehr hoch im Kurs, da sie gerade für Ablaufbeschreibungen schnell zu verstehen sind und teilweise auch schneller erstellt sind, als ein langer Text. Wie erstellt ihr eure Dokumentationen und macht ihr sie überhaupt?

Es ist Sonntag und ich überlege ob ich zocke oder programmiere, doch bevor ich mich dieser extrem schweren Frage stelle noch eine kleine News für zwischendurch. Dieses Mal geht es um Android Libraries und die Anzahl an Methoden die sie mitbringen. Jeder Android Entwickler kennt vermutlich das 64K DEX Limit und wird hier und dort schon einmal nervige Erfahrungen mit Multi-DEX gemacht haben. Auch wenn dies ein geringeres Problem in neueren Android Versionen darstellt, ist es trotzdem störend. Denn sobald man Multi-DEX nutzt kann das bauen länger dauern, hier und dort können kryptische Fehler entstehen und gerade bei ganz neuen Android Studio Features kann es Probleme geben. Deswegen habe ich gerade erst bei einem großen Projekt mit hängen und würgen diverse Methoden aus fremden Libraries entfernt, um unter das magische DEX Limit zu kommen. Dazu gibt es bald noch einen Beitrag. Doch die Ernüchterung kam bald, denn abgesehen davon das die Android Support Libraries extrem viele Methoden am Start haben, gab es bald eine neue Abhängigkeit und zwar die Google Services. Damit war dann jegliche Chance verloren unter das DEX Limit zu kommen. Denn mit 20K+ Methoden für diverse Android Support Komponenten und dann noch ca. 8K für eine Komponente der Google Services ist man schon so extrem weit oben was den Method-Count angeht. Ich verstehe wie komplex diese Dinge sind und was Google so nah am System wohl alles bauen und bedenken muss, doch ein wenig mehr Augenmerk auf diese Komponenten mit Bezug auf die Anzahl der Methoden wäre hin und wieder sehr angenehm. In diesem Kontext ist mir bewusst das die Android Support und Google Services Libraries in der letzten Zeit in kleinere Pakete zerteilt wurden, was ich extrem gut finde, doch irgendwie reicht dies leider noch nicht aus. Für mich heißt es nun back to Multi-DEX und mit den eventuellen Problemen auskommen. Wie ist es bei euch, kennt ihr das Problem und wie umgeht ihr es bei euch, sofern dies möglich ist?

Neue Woche neue Themen, dieses Mal geht es darum wie wichtig es ist das vor der eigentlichen Implementierung alle Rahmenbedingungen und nötigen Komponenten geplant und definiert sind. Denn egal ob man privat etwas entwickelt oder professionell, merkt man mitten in die Implementierung das z.B. die Icons fehlen ist dies störend. Aus diesem Grund sollte man immer versuchen aus verschiedenen Perspektiven auf das zu entwickelnde zu blicken und entsprechend zu überlegen was alles involviert ist. Basierend darauf kann man dann zu einem Zeitpunkt X entscheiden ob alles nötige für die Aufgabe bereits vorhanden ist. Dabei ist es natürlich auch möglich einiges durch Platzhalter zu ersetzen, z.B. wenn es um Icons geht. Doch dies ist natürlich nur sehr beschränkt möglich wenn man z.B. mit einem Server bzw. einer API reden muss und diese Daten weiterverarbeiten will. Hier sind natürlich Mock-Daten eine Möglichkeit, aber nichts ist so gut wie reale Daten. Denn auch so etwas wie Mock-Daten muss erst einmal erstellt und an die Entwickler verteilt werden. Beachtet man die genannten Regeln nicht wird es im besten Fall etwas nervig für die Entwickler, im schlechtesten blockiert man die Entwicklung und verschwendet Ressourcen. Auch wenn letzteres natürlich wesentlich negativer ist als zuerst genanntes, man sollte beides vermeiden, denn ein frustrierter Entwickler ist wahrlich nichts was man möchte. Vor allem übrigens in kleinen privaten Projekten, wo niemand als Project Owner / Manager o.ä. Pläne macht, geht so etwas leicht unter. Auch hier sollte man also lieber ein paar Stunden mehr Zeit in Überlegungen und Planung stecken, als am Ende mit einem halbfertigen Produkt dazustehen, weil viele Kleinteile im großen Konstrukt einfach fehlen.