Boehrsi.de - Blog

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.

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?

Das Jahr 2017 ist bereits in vollem Gange und neben meinem Gaming Review für das letzte Jahr, möchte ich auch die Planungen für das aktuelle Blog Jahr etwas mit euch teilen. Denn die einen oder anderen große und kleine Pläne habe ich bereits. An erster Stelle steht der komplette Rewrite meiner Website mittels völlig anderen Techniken, sodass ich eine statische Seite nutzen kann. Diese wird um kleinere dynamische Komponenten ergänzt, sodass z.B. Kommentare möglich sein werden. Für die Umsetzung werde ich Hugo open_in_new nutzen. Aktuell lese ich mir dort noch etwas Wissen an, danach folgen ein paar kleinere Tests und die Entwicklung des Themes. Abschließend erfolgt dann die eigentliche Implementierung. Aufgrund diverser anderer Dinge, wie z.B. das tägliche Leben, gibt es dafür aktuell noch keinen festen Zeitplan oder dergleichen. Sobald ich allerdings etwas konkreter weiß was Sache ist oder es vorzeigbare Fortschritte gibt melde ich mich natürlich wieder. Diverse weitere Pläne und Ideen werde ich in den weiteren Teilen der Newsreihe verarbeiten und solltet ihr noch Ideen oder Kommentare haben meldet euch einfach direkt unter dieser News.

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.