Boehrsi.de - Blog

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.

Das ich aktuell gerne Rainbow Six Siege spiele dürften die meisten Leser im Blog glaube ich mitbekommen haben, denn ich berichte häufiger über den Shooter von Ubisoft. Ich berichte über neue Updates, DLCs und ähnliches. Zu meckern hatte ich bis dato sehr wenig und auch mit kleineren Bugs / Glitches konnte ich mich immer recht gut arrangieren. Doch das letzte Update änderte dies, denn obwohl es diverse Fehler beheben sollte, hat es das Spiel unspielbar für mich gemacht. Ich kann maximal eine Runde abschließen, denn ansonsten gibt es einen Verbindungsabbruch oder alternativ einen Crash. Dazu sei gesagt das ich zuvor noch nie einen Verbindungsabbruch hatte, abgesehen natürlich von Zeiten wo die Server allgemein Probleme hatten. Crashs gab es ebenfalls sehr wenig und in den letzten Monaten absolut gar nicht mehr, bis zum genannten 2.1.1 Patch. Abgesehen von diesen Gamebreaking Bugs gibt es diverse neue kleine Probleme und einige der eigentlich behobenen Probleme sind auch zurück. Ich denke Ubisoft hat mit diesem Update leider die QA etwas vernachlässigt und sich mehr Probleme geschaffen als gelöst. Ich persönlich hoffe auf die baldige Lösung der Probleme, denn Rainbow Six Siege ist aktuell das einzige Multiplayer-Spiel welches ich wirklich gerne und umfangreich Spiele. Ein Battlefield 1 macht zwar auch Spaß, kommt für mich aber nicht einmal ansatzweise an Rainbow heran. Ich würde mich freuen wenn Ubisoft aus ihren Fehlern hier lernt und z.B. Community Test-Server bereitstellt, so wie es schon bei The Division erfolgreich getan wurde.

• Rainbow Six Siege Webseite open_in_new
• Rainbow Six Siege auf Amazon kaufen open_in_new

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.

Neben meinen Plänen die Technik hinter meinem Blog zu vereinfachen und zu optimieren, bin ich in den letzten Tagen auch häufig über die Idee gestolpert ebenfalls das Design noch etwas zu verfeinern. Kleinigkeiten sind ohnehin geplant, aber nachdem ich in der letzten Zeit viel mit Googles Material Design Ansatz herum gespielt habe, überlege ich diesen noch etwas mehr einfließen zu lassen. Aktuell benutze ich bereits ein paar der Ideen, aber eher unstrukturiert und nur dort wo ich es sinnvoll finde. Dadurch ergibt sich nicht immer ein klares Design und dies könnte besser sein. Ich denke ich werde mein altes Design auf jeden Fall als große Basis nehmen und nicht von vorne anfangen. Darauf basierend gibt es dann kleinere und größere Anpassungen, die ich dann Stück für Stück testen werde. Falls ihr Anregungen zum aktuellen Design, Google Material Design oder meinem Blog im allgemeinen habt, meldet euch gerne in den Kommentaren. Ich freue mich über jedes Feedback.

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.

Die erste monatliche Zusammenfassung im neuen Jahr. Heute gibt es mal wieder die beliebtesten Beiträge aus dem Blog, zusammengefasst in einer schönen Top 10 Liste. Die gewohnte absteigende Sortierung ist auch im neuen Jahr noch gegeben. Vor allem neue und frische News sind dieses Mal auf den ersten Plätzen vertreten, während ein paar dauerhaft beliebte Beiträge natürlich auch wie immer mal wieder rein schauen. Werft ruhig einen schnellen Blick auf die unten stehende Liste, sie bietet wie gewohnt einen guten Überblick ob man vielleicht interessante News in der letzten Zeit übersehen hat.

In diesem Teil möchte ich einen kleinen Ausblick geben was ich mir in Sachen Reichweite für dieses Jahr vorstelle. Letztes Jahr war ich mit 255.928 Unique Visitors am Start und es gab 1.945.411 Aufrufe auf meiner Seite. Verglichen mit dem Vorjahr 2015 (Unique Visitors: 221.207, Aufrufe: 1.413.840) ist dies eine Steigerung von ca. 15% bzw. ca. 35% in den beiden genannten Bereichen und damit bin ich recht zufrieden. Was ich schade finde ist die geringe Anzahl an Kommentaren (2016: 117, 2015: 256). Dies ist eine der Hauptsachen die ich steigern will, denn dieser Wert ist mir ziemlich wichtig. Im Bereich Besucher möchte ich gerne die 300.000 schaffen und nebenbei wären 2.200.000 Aufrufe super. Um diese Ziele zu erreichen muss ich etwas mehr Gas geben und dafür will ich vor allem etwas mehr und konkreteren Content erstellen und euch mehr einbinden. Solltet ihr als Leser also Ideen haben, nur raus damit! Ich freue mich immer über Vorschläge, hinterlasst diese gerne direkt hier unter der News.

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?

Abgesehen von den größeren Umbauarbeiten die ich für meine Seite dieses Jahr plane, gibt es auch einige inhaltliche Änderungen die ich durchziehen möchte. Allem voran geht es darum News-Sammlungen wirklich fortzuführen oder entsprechend zu beenden. Denn zu häufig kündige ich News an und schreibe sie dann gar nicht oder erst Monate später. Dies ist mitunter fehlender Zeit geschuldet, vor allem wenn es um umfangreichere Beiträge geht, aber häufig vergesse ich Dinge auch einfach oder bin zu faul. Deswegen werde ich meinen Software-Stack zum Erstellen von News und zum notieren von Themen in der nächsten Zeit etwas optimieren. Zum einen habe ich mit Google Notizen und Pocket eigentlich Plattformen die mir bei genanntem Problem helfen, doch dafür muss ich sie auch nutzen. Zum anderen habe ich vor handschriftlich etwas mehr zu notieren, denn ein paar Notizzettel am Monitor helfen mir meistens am Besten. Ich hoffe ich kann meine Pläne in diesem Bereich umsetzen, denn halbfertige Sachen stören mich selbst wohl am meisten.